--- Log opened Sun Jan 29 00:00:17 2017
--- Day changed Sun Jan 29 2017
20170129 00:00:17< RatArmy_> Is there GSoC for wesnoth anymore?
20170129 00:00:38< RatArmy_> 2015&2016 was nothing.
20170129 00:01:38< zookeeper> doesn't seem like it.
20170129 00:07:10-!- travis-ci [~travis-ci@ec2-54-161-212-239.compute-1.amazonaws.com] has joined #wesnoth-dev
20170129 00:07:11< travis-ci> wesnoth/wesnoth#12580 (no_on_redo - ebd0741 : gfgtdf): The build failed.
20170129 00:07:11< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/196242185
20170129 00:07:11-!- travis-ci [~travis-ci@ec2-54-161-212-239.compute-1.amazonaws.com] has left #wesnoth-dev []
20170129 00:08:50-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has joined #wesnoth-dev
20170129 00:11:39-!- elias [~allefant@allegro/developer/allefant] has joined #wesnoth-dev
20170129 00:15:58< RatArmy_> zookeeper: thanks
20170129 00:16:07-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has quit [Remote host closed the connection]
20170129 00:35:50-!- gfgtdf [~chatzilla@x50ab6e9d.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20170129 00:35:57-!- gfgtdf [~chatzilla@x50ab6e9d.dyn.telefonica.de] has joined #wesnoth-dev
20170129 00:51:37-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Read error: Connection reset by peer]
20170129 00:52:04-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170129 01:02:14-!- gfgtdf [~chatzilla@x50ab6e9d.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170129 01:04:01-!- gfgtdf [~chatzilla@x50ab6e9d.dyn.telefonica.de] has joined #wesnoth-dev
20170129 01:25:31-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20170129 01:31:31-!- Bhoren [~Bhoren_wi@LAubervilliers-656-1-270-96.w193-248.abo.wanadoo.fr] has joined #wesnoth-dev
20170129 01:38:24-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170129 01:44:46< irker743> wesnoth: gfgtdf wesnoth:no_on_redo 7d3de6ec60c3 / src/actions/undo.cpp: fixup 1 https://github.com/wesnoth/wesnoth/commit/7d3de6ec60c3ef9957060af000afa9b5cd575e72
20170129 01:51:38-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 276 seconds]
20170129 01:54:31-!- louis94 [~~louis94@199.35-245-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 255 seconds]
20170129 01:54:57-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170129 01:56:43-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170129 02:04:07-!- louis94 [~~louis94@199.35-245-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20170129 02:11:45-!- gfgtdf [~chatzilla@x50ab6e9d.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
20170129 02:12:32-!- gfgtdf [~chatzilla@x50ab6e9d.dyn.telefonica.de] has joined #wesnoth-dev
20170129 02:31:08-!- louis94 [~~louis94@199.35-245-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 240 seconds]
20170129 02:43:25-!- Bhoren [~Bhoren_wi@LAubervilliers-656-1-270-96.w193-248.abo.wanadoo.fr] has quit [Read error: Connection reset by peer]
20170129 02:45:09-!- travis-ci [~travis-ci@ec2-54-221-31-255.compute-1.amazonaws.com] has joined #wesnoth-dev
20170129 02:45:10< travis-ci> wesnoth/wesnoth#12581 (no_on_redo - 7d3de6e : gfgtdf): The build was fixed.
20170129 02:45:10< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/196255405
20170129 02:45:10-!- travis-ci [~travis-ci@ec2-54-221-31-255.compute-1.amazonaws.com] has left #wesnoth-dev []
20170129 02:47:03-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has joined #wesnoth-dev
20170129 02:51:35-!- gfgtdf [~chatzilla@x50ab6e9d.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170129 02:52:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170129 02:53:07-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 02:54:28-!- atarocch [~atarocch@151.41.103.34] has quit [Remote host closed the connection]
20170129 03:11:40-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170129 03:11:46-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170129 03:12:15-!- RatArmy_ [~ratarmy@om126212249033.14.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170129 03:27:39-!- Coffee_irc [~david@ppp121-45-82-79.bras1.adl6.internode.on.net] has joined #wesnoth-dev
20170129 03:36:35-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170129 03:37:11-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 03:50:30< Coffee_irc> hi all
20170129 03:51:19< Coffee_irc> whilst not being an active dev for a while now, I recently put some time into solving network disconnection detections
20170129 03:51:30< Coffee_irc> longstanding bug https://gna.org/bugs/?func=detailitem&item_id=24042
20170129 03:52:24< Coffee_irc> I think I have working code to do this, but requires minor changes to the server code and the way ping test work
20170129 03:53:39< Coffee_irc> is the dev cycle still going for new code (that really requires a bit of testing)?
20170129 03:57:23-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has quit [Remote host closed the connection]
20170129 04:06:12-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20170129 04:06:22< Coffee_irc> if anyone is interested, here's my patch for this http://pastebin.com/0xktnYSE
20170129 04:07:10< Coffee_irc> I've set a 3 second ping between the wesnothd server and clients with forced disconnect after 5 missed pings
20170129 04:07:29< Coffee_irc> with output in the terminal that shows how many pings are missed
20170129 04:07:53-!- gfgtdf_ [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 04:10:35< Coffee_irc> the issue is one that regularly crops up in play from experience, and thought to be because most ISPs change the dynamic Internet address relatively often
20170129 04:10:35-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170129 04:10:48-!- gfgtdf_ is now known as gfgtdf
20170129 04:11:09-!- RatArmy_ [~ratarmy@om126212249033.14.openmobile.ne.jp] has joined #wesnoth-dev
20170129 04:14:53-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 51.0.1/20170125094131]]
20170129 04:15:08< Coffee_irc> such code could be adapted perhaps to gracefully transfer the socket to the new Internet address to continue the game seamlessly (instead of the current silent disconnect)
20170129 04:29:00< Coffee_irc> ultimately what I'd be after is a ping timeout of say 30 seconds, from the server to each client
20170129 04:29:25< Coffee_irc> with a message on the client end if one gets missed, 2, etc. until after 'n' missed pings it tries to handshake and transfer the socket, or autodisconnects if this fails
20170129 04:34:24-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has joined #wesnoth-dev
20170129 04:34:55-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has quit [Remote host closed the connection]
20170129 05:18:50< Aginor> Coffee_irc: I think that providing feedback about players being disconnected from the network is a good thing
20170129 05:19:17< Aginor> the auto transfer of sockets thing, it sounds pretty much like a disconnected player being allowed to rejoin an ongoing game
20170129 05:19:24< Coffee_irc> hi Aginor
20170129 05:19:32< Coffee_irc> yeah
20170129 05:19:51< Coffee_irc> I think there is/was code designed to do this, but it never worked properly
20170129 05:20:08< Coffee_irc> in the settings there is a "ping timeout" feature
20170129 05:20:26< Aginor> (I haven't looked at it myself)
20170129 05:21:00< Coffee_irc> my test code appears to work, but I need access to the server code and maybe set up a new branch for some testing
20170129 05:22:09< Coffee_irc> I don't mean the git repository, but the actual code that you connect to when you click "official server" on master
20170129 05:23:10< Coffee_irc> it is easy to replicate if you have access to 2 separate Internet connections to switch (e.g. fixed ADSL and mobile Internet)
20170129 05:24:45< Aginor> well, yes
20170129 05:25:06< Coffee_irc> with the rejoining, I'd like to keep the game state and transfer the socket so it appears as though nothing happened for the player
20170129 05:25:13< Coffee_irc> rather than a quit/rejoin
20170129 05:25:24< Coffee_irc> this is how most IRC clients appear to work
20170129 05:25:38< Aginor> I think it should be a quit/rejoin, but the client should be allowed to do that itself
20170129 05:26:02< Coffee_irc> the konversation app actually does an auto socket move
20170129 05:26:12< Aginor> although you'll have to notify the player of what's going on, have a backoff period for failures etc
20170129 05:26:14< Coffee_irc> and so you don't notice that your Internet address has changed
20170129 05:26:41< Aginor> Coffee_irc: it probably does what we're talking about behind the scenes
20170129 05:26:49< Coffee_irc> all the buffers for send/receive are ready, just need redirecting
20170129 05:27:39< Coffee_irc> many apps that use boost appear to have this kind of thing built in
20170129 05:28:13< Coffee_irc> I'd like to create a separate branch with my changes/testing to try to achieve this outcome
20170129 05:28:25< Aginor> http://stackoverflow.com/questions/3062803/how-do-i-cleanly-reconnect-a-boostsocket-following-a-disconnect
20170129 05:28:55< Coffee_irc> oh, ok
20170129 05:28:56< Aginor> the server will see it as a new connection from the client
20170129 05:29:04< Coffee_irc> I don't intend for it to be disconnected though
20170129 05:29:12< Coffee_irc> just to transfer the socket
20170129 05:29:17< Coffee_irc> to the new address
20170129 05:30:05< Coffee_irc> everything should automatically resume where it left off
20170129 05:31:33< Coffee_irc> so you would see the ping timeout go past a certain marker that triggers a new socket connection with the same handle set
20170129 05:31:54< Coffee_irc> the server would see the same handle, drop the new socket and reallocate the other socket to the new address
20170129 05:32:00< Coffee_irc> no disconnection from the server side
20170129 05:32:48< Coffee_irc> game in progress continues
20170129 05:33:55< Aginor> I'm not sure we talk about the same things with sockets
20170129 05:34:28< Coffee_irc> I'd need to test this on a separate test branch, but I believe it is reasonably easy to implement
20170129 05:35:24< Coffee_irc> Aginor: yes, you are talking about a different scenario
20170129 05:36:26< Aginor> I'm talking about network sockets
20170129 05:36:47< Coffee_irc> this scenario perhaps doesn't need to be coded as you would just reconnect to the lobby and rejoin the game
20170129 05:36:48< Aginor> the association with sockets and ongoing games will have to be handled differently
20170129 05:37:19< Aginor> network sockets cannot be transferred, but you can associate a new/different one with an ongoing session
20170129 05:37:37< Coffee_irc> if I get it right this kind of reconnect would be because of an error being thrown causing a disconnect
20170129 05:38:01< Aginor> network sockets are by their very definition not transfarrable as they are identified by src and dst ips and ports and protocol
20170129 05:38:08< Coffee_irc> you are right
20170129 05:38:23< Aginor> this is why I'm a bit confused :)
20170129 05:38:38< Coffee_irc> all the buffers would need to be transferred to a new socket in place of the original one
20170129 05:39:05< Aginor> you will most likely need to sync gamestate as well, as there may have been dataloss
20170129 05:39:30< Aginor> in fact, the disconnect will have been detected because of dataloss
20170129 05:39:41< Coffee_irc> ah, not so
20170129 05:39:59< Coffee_irc> the scenario I'm trying to cover is when the IP address of a client changes
20170129 05:40:02< Aginor> the server tried to sent the client data. The data timed out
20170129 05:40:21< Coffee_irc> the server never detects this
20170129 05:40:28< Coffee_irc> data never times out
20170129 05:40:35< Coffee_irc> leading to the initial problem
20170129 05:41:03< Coffee_irc> the send from the server is just always waiting for an address to become available that doesn't
20170129 05:41:12< Aginor> until you detect a disconnect, (for whatever reason), you will have data in flight
20170129 05:41:35< Aginor> whether the data is game data, or a ping packet, or an ICMP echo request/reply doesn't matter
20170129 05:41:45< Coffee_irc> you are right
20170129 05:41:55< Coffee_irc> so the send buffer/receive buffer should be transferred
20170129 05:42:04< Coffee_irc> and the game continues as before
20170129 05:42:17< Aginor> there is no guarantee that it is the client that makes the discovery first
20170129 05:42:37< Coffee_irc> ah
20170129 05:42:43< Coffee_irc> this is where the confucion lies
20170129 05:42:52< Coffee_irc> the server will never detect the problem
20170129 05:43:02< Aginor> how?
20170129 05:44:51< Coffee_irc> it will look like the client just is waiting forever
20170129 05:44:51< Aginor> no...
20170129 05:44:51< Coffee_irc> and the game will continue on and on from the server perspective
20170129 05:44:51< Aginor> there'll be a timeout on the transmission
20170129 05:44:51< Coffee_irc> doesn't happen (in any reasonable timeframe)
20170129 05:44:51< Coffee_irc> again, this is easy to test
20170129 05:44:51< Coffee_irc> if you have 2 separate Interent connections
20170129 05:44:51< Coffee_irc> AFAICT this is the intended TCP implementation
20170129 05:44:57< Aginor> no need for messing around with that, just switch between two static ip addresses, it'll break just as well
20170129 05:45:33< Coffee_irc> this is what I have done locally to test
20170129 05:46:02< Coffee_irc> this took me a while to understand myself
20170129 05:46:23< Coffee_irc> I looked at the official boost implementation docs for how to do this and why
20170129 05:46:25< Coffee_irc> http://www.boost.org/doc/libs/1_45_0/doc/html/boost_asio/example/timeouts/async_tcp_client.cpp
20170129 05:46:29< Aginor> I think that you assume that the connection switch is faster than the TCP timeout
20170129 05:46:40< Coffee_irc> TCP timeout does not happen
20170129 05:47:06< Aginor> this is where I get confused
20170129 05:47:20< Coffee_irc> in the official docs there are 2 deadline timers for checking for disconnects
20170129 05:47:44< Coffee_irc> one keeps a patten that says ever say 10 seconds check if we are still here
20170129 05:48:08< Coffee_irc> and then each time this happens a second timer is used as a "heartbeat" to send back a signal
20170129 05:48:30< Aginor> yeah, the heartbeat looks like a standard keepalive protocol
20170129 05:48:37< Coffee_irc> so on the client and server side, each receive also needs a send as part of it
20170129 05:48:57< Aginor> the deadline looks like your general TCP transmission timeout
20170129 05:49:16< Coffee_irc> yeah, it would be similar
20170129 05:49:44< Aginor> hmm
20170129 05:49:45-!- RatArmy_ [~ratarmy@om126212249033.14.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170129 05:49:48< Coffee_irc> by default this TCP transmission timeout is infinite
20170129 05:49:53< Coffee_irc> or very large
20170129 05:50:01< Aginor> but it's all done one layer above what already happens
20170129 05:50:07< Coffee_irc> and the intended TCP implementation AFAICT
20170129 05:51:04< Coffee_irc> this is why it is intended that you use a heartbeat when sending async_read/write from boost server/client models
20170129 05:51:20< Coffee_irc> according to the official docs AFAICT
20170129 05:51:51-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has joined #wesnoth-dev
20170129 05:52:28< Aginor> ok
20170129 05:52:32< Coffee_irc> with the heatbeat implementation both server and client know when something is not sending
20170129 05:52:44< Aginor> I'm talking transport layer, I think you're talking application layer
20170129 05:53:11< Coffee_irc> yes
20170129 05:53:49< Coffee_irc> maybe it is easier to put a TCP-transmission timer, but I believe this would not be recommended or implemented properly across all platforms
20170129 05:54:13< Aginor> no, now when I understand you, I agree
20170129 05:54:25< Coffee_irc> as far as I understand this goes against TCP recommended practises
20170129 05:54:56< Aginor> If you want to quickly determine a problem with the connection, you cannot affort to wait for TCP to do it for you
20170129 05:55:02< Coffee_irc> this too
20170129 05:55:03< Aginor> as it may take many minutes
20170129 05:55:12< Coffee_irc> as it can also be in a semi-ready state
20170129 05:55:40< Coffee_irc> this bug has been a bugbear for me for over 2 years on/off :P
20170129 05:55:49< Aginor> hehe
20170129 05:56:01< Aginor> application layer keepalive, all good
20170129 05:56:33< Aginor> track state across client and server, with a number or whatever (I have no idea how this works in wesnoth)
20170129 05:56:51< Coffee_irc> do you know how I might do some testing on the server side code to make this happen?
20170129 05:57:12< Aginor> I think the official game servers run the same code as what's in git
20170129 05:57:15< Coffee_irc> I can create a branch for my changes
20170129 05:57:31< Aginor> definitively do a branch :D
20170129 05:57:53< Coffee_irc> so if I make a branch on master git then the official server will also compile and run this code?
20170129 05:58:17< Aginor> why do you need to deploy it on a server?
20170129 05:59:01< Aginor> you can simulate all of this without having to do any deployments on any servers, simply set up two VMs at home, one that's a server and one that's a client
20170129 05:59:24< Coffee_irc> at some point I'd need to test this on the official server
20170129 05:59:26< Aginor> you can then introduce as much latency, loss, or whatever else you need to simulate the worst possible network conditions
20170129 06:01:16< Aginor> http://stackoverflow.com/questions/614795/simulate-delayed-and-dropped-packets-on-linux
20170129 06:02:25< Aginor> what would you hope to achieve by putting it on the official server unless you also roll out code to the clients so they understand it?
20170129 06:03:49-!- Coffee_irc [~david@ppp121-45-82-79.bras1.adl6.internode.on.net] has quit [Ping timeout: 255 seconds]
20170129 06:04:19-!- Bonobo [~Bonobo@2001:44b8:254:3200:35ed:41fc:466a:ed3a] has quit [Ping timeout: 255 seconds]
20170129 06:04:34-!- Coffee_irc [~david@ppp118-210-252-236.bras1.adl4.internode.on.net] has joined #wesnoth-dev
20170129 06:04:57< Coffee_irc> ironic that my Internet cut out here :P
20170129 06:05:08< Coffee_irc> a family member unplugged the modem whilst vacuuming
20170129 06:05:28< Aginor> heh
20170129 06:05:36< Aginor> 18:59 < Aginor> you can then introduce as much latency, loss, or whatever else  you need to simulate the worst possible network conditions
20170129 06:05:39< Aginor> 19:01 < Aginor> http://stackoverflow.com/questions/614795/simulate-delayed-and-dropped-packets-on-linux
20170129 06:05:42< Aginor> 19:02 < Aginor> what would you hope to achieve by putting it on the official  server unless you also roll out code to the clients so they  understand it?
20170129 06:06:10< Coffee_irc> Aginor: dropped packets I don't think are a concern
20170129 06:06:26< Coffee_irc> the TCP implementation should handle that and ordering, etc.
20170129 06:06:35< Coffee_irc> all in the boost:asio stuff
20170129 06:07:13< Aginor> Coffee_irc: it's a concern on how your application level keepalive will behave when there's heavy latency and packet loss, etc
20170129 06:07:25-!- Bonobo [~Bonobo@ppp118-210-252-236.bras1.adl4.internode.on.net] has joined #wesnoth-dev
20170129 06:08:04< Coffee_irc> yeah, this is why I put an amount of failed pings
20170129 06:08:18< Coffee_irc> and intend for a notification of a "bad network" beforehand
20170129 06:08:37< Coffee_irc> I suppose this should all be tested
20170129 06:08:50< Aginor> ok
20170129 06:08:57< Coffee_irc> it would also increase the total server traffic
20170129 06:09:02< Aginor> I'd say so
20170129 06:09:46< Coffee_irc> this is why I tried initially to just send a blank packet between server/client as a "pingtest"
20170129 06:11:00< Coffee_irc> maybe this is the way to go still
20170129 06:12:09< Coffee_irc> I think what I should do is start up a branch on master for these changes and commit them there
20170129 06:12:35< Coffee_irc> implementing these various new features as separate commits
20170129 06:12:40< Aginor> yes, please do it in a branch somewhere
20170129 06:12:45< Aginor> not directly in master
20170129 06:13:30< Coffee_irc> I just wanted to make sure that new code is still being accepated for wesnoth in the dev cycle as this would be a reasonably major change
20170129 06:13:39< Coffee_irc> *accepted
20170129 06:13:53< Aginor> I don't know about that, I haven't been paying much attention the last few months
20170129 06:14:06< Aginor> I think the GUI code is still being rewritten
20170129 06:14:19< Aginor> vultraz would know
20170129 06:15:01< Coffee_irc> I'd like to get a fully working model with preference entries and all the niceties/code indenting, etc. and hope for inclusion before 1.14.0
20170129 06:16:33< Aginor> I don't know if there's a release plan, but I think 1.14 is probably a while away still
20170129 06:16:52< Coffee_irc> good to know and thanks for the chat Aginor
20170129 06:17:11< Aginor> I haven't seen any messages about a feature freeze, but if it was only announced on IRC I'll most likely have missed it
20170129 06:17:27< Coffee_irc> do have to leave at the moment for some soccer ;)
20170129 06:17:34< Aginor> soccer well
20170129 06:17:44< Aginor> I shall go and do some work
20170129 06:17:55< Coffee_irc> cheers Aginor
20170129 06:18:44-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has quit [Remote host closed the connection]
20170129 06:19:36-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has joined #wesnoth-dev
20170129 06:20:58-!- celticminstrel is now known as celmin|sleep
20170129 06:22:47< Aginor> good night celmin|sleep 
20170129 06:39:52-!- irker743 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170129 07:11:02-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170129 07:11:03-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170129 07:22:14-!- Coffee_irc [~david@ppp118-210-252-236.bras1.adl4.internode.on.net] has quit [Ping timeout: 258 seconds]
20170129 07:35:43-!- JyrkiVesterinen [~JyrkiVest@87-92-20-117.bb.dnainternet.fi] has joined #wesnoth-dev
20170129 07:40:47-!- Kwandulin [~Miranda@p200300760F6EBF6E01B6EDF54131DA25.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170129 07:52:38-!- crossbreed [~crossbree@xdsl-89-0-85-194.netcologne.de] has quit [Quit: This computer has gone to sleep]
20170129 08:00:34-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has quit [Remote host closed the connection]
20170129 08:32:54-!- Coffee_irc [~david@ppp118-210-252-236.bras1.adl4.internode.on.net] has joined #wesnoth-dev
20170129 08:41:11-!- madmax28 [~max@xdsl-89-0-85-194.netcologne.de] has joined #wesnoth-dev
20170129 08:57:11< JyrkiVesterinen> Coffee_irc: As Aginor said, 1.14.0 is a while away.
20170129 08:57:47< JyrkiVesterinen> Ever since vultraz got a new PC (he hasn't managed to set up a development environment on it yet), progress on Wesnoth has been quite slow.
20170129 08:58:29< JyrkiVesterinen> You should be easily able to finish the feature in time for 1.14.
20170129 09:01:15-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has joined #wesnoth-dev
20170129 09:02:48-!- RatArmy_ [~ratarmy@om126212249033.14.openmobile.ne.jp] has joined #wesnoth-dev
20170129 09:04:55< Coffee_irc> JyrkiVesterinen: thanks, I'll set up a branch later tonight
20170129 09:05:43< Coffee_irc> I'll probably only be able to get to working on this on and off, so this is good news for me
20170129 09:07:01-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has quit [Ping timeout: 255 seconds]
20170129 09:24:38< loonycyborg> Coffee_irc: new wesnothd can enable SO_KEEPALIVE
20170129 09:24:39-!- RatArmy_ [~ratarmy@om126212249033.14.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170129 09:25:01< loonycyborg> this is transparent way of keeping track of disconnected peers
20170129 09:25:26< loonycyborg> though by default it takes many hours before it starts sending probes
20170129 09:25:51< loonycyborg> iirc we have it enabled on wesnoth.org's wesnothd
20170129 09:28:38-!- Kwandulin [~Miranda@p200300760F6EBF6E01B6EDF54131DA25.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170129 09:45:42-!- Kwandulin [~Miranda@p200300760F6EBF6E3D4BE303CD8DC5AC.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170129 09:58:41-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20170129 10:10:25-!- Coffee_irc [~david@ppp118-210-252-236.bras1.adl4.internode.on.net] has quit [Ping timeout: 255 seconds]
20170129 10:21:34-!- RatArmy_ [~ratarmy@om126212249033.14.openmobile.ne.jp] has joined #wesnoth-dev
20170129 10:36:35-!- RatArmy_ [~ratarmy@om126212249033.14.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170129 10:43:28-!- RatArmy_ [~ratarmy@om126212249033.14.openmobile.ne.jp] has joined #wesnoth-dev
20170129 11:04:01-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has joined #wesnoth-dev
20170129 11:06:04-!- mjs-de [~mjs-de@x4db6ab27.dyn.telefonica.de] has joined #wesnoth-dev
20170129 11:08:31-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has quit [Ping timeout: 255 seconds]
20170129 11:16:44-!- Bhoren [~Bhoren_wi@LAubervilliers-656-1-270-96.w193-248.abo.wanadoo.fr] has joined #wesnoth-dev
20170129 11:18:24-!- horrowind [~Icedove@2a02:810a:83c0:e4b4:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20170129 11:23:06-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170129 11:36:23-!- JyrkiVesterinen [~JyrkiVest@87-92-20-117.bb.dnainternet.fi] has quit [Quit: .]
20170129 11:49:56-!- Kwandulin [~Miranda@p200300760F6EBF6E3D4BE303CD8DC5AC.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170129 12:10:29-!- louis94 [~~louis94@199.35-245-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20170129 12:17:41-!- irker006 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170129 12:17:41< irker006> wesnoth: Wedge009 wesnoth:master ee7ea31eb256 / projectfiles/VC12/ (wesnoth.vcxproj wesnoth.vcxproj.filters): addon_list.cpp: Add missing configuration for VC Release build. https://github.com/wesnoth/wesnoth/commit/ee7ea31eb25608c553c5d1d20f4412eea74259ab
20170129 12:19:30-!- louis94 [~~louis94@199.35-245-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 256 seconds]
20170129 12:32:21-!- Duthlet [~Duthlet@dslb-188-105-120-162.188.105.pools.vodafone-ip.de] has joined #wesnoth-dev
20170129 12:36:08-!- madmax28 [~max@xdsl-89-0-85-194.netcologne.de] has quit [Ping timeout: 240 seconds]
20170129 12:50:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170129 12:57:09-!- madmax28 [~max@xdsl-89-0-85-194.netcologne.de] has joined #wesnoth-dev
20170129 12:59:15-!- Coffee_irc [~david@ppp118-210-252-236.bras1.adl4.internode.on.net] has joined #wesnoth-dev
20170129 13:04:54-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has joined #wesnoth-dev
20170129 13:05:27-!- louis94 [~~louis94@199.35-245-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20170129 13:07:08-!- JyrkiVesterinen [~JyrkiVest@87-92-20-117.bb.dnainternet.fi] has joined #wesnoth-dev
20170129 13:08:46-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 13:09:33-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has quit [Ping timeout: 255 seconds]
20170129 13:10:05< gfgtdf> zookeeper: you know whether there is some easy way to reinsert a first_time_only=false event on undo ?
20170129 13:10:54< zookeeper> i don't think so
20170129 13:11:27< zookeeper> but, uh, i'm not actually sure what you mean
20170129 13:11:44< zookeeper> if it's false then it hasn't gone anywhere...
20170129 13:12:07< gfgtdf> zookeeper: i menat first_time_only=yes
20170129 13:12:25< zookeeper> ok, in that case... i don't think so :P
20170129 13:12:44< zookeeper> why do you ask?
20170129 13:15:35< gfgtdf> zookeeper: becaue i came to the conclusion that code like this http://pastebin.com/BvBgg7KM casue OOS, esactly becasue the even won't be executed because the next time a moveto event happens after the first one was undone
20170129 13:16:12-!- Kwandulin [~Miranda@p200300760F6EBF6EC8C9E53B07E0D490.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170129 13:16:42< gfgtdf> zookeeper: whil with first_time_only=yes it shouldnt casue OOS (well it does but that another bug im currently fixing)
20170129 13:17:30< gfgtdf> zookeeper: but i wondered whther there is a OOS-save way to do this while firing this only once still
20170129 13:18:58< zookeeper> "won't be executed because the next time a moveto event happens after the first one was undone" <- no idea what that means
20170129 13:19:05-!- madmax28 [~max@xdsl-89-0-85-194.netcologne.de] has quit [Ping timeout: 240 seconds]
20170129 13:19:22< zookeeper> anyways, back in 15 mins or so ->
20170129 13:21:58-!- DeFender1031 [~DeFender1@89-139-107-49.bb.netvision.net.il] has quit [Read error: Connection reset by peer]
20170129 13:22:00< gfgtdf> zookeeper: hzmm yes that wasnt very clear. It just currently casues OOS and some tag like [readd_event_on_undo] woudl fix that.
20170129 13:22:50-!- DeFender1031 [~DeFender1@dsl217-132-26-157.bb.netvision.net.il] has joined #wesnoth-dev
20170129 13:25:10< Kwandulin> Mhh, {PLACE_IMAGE} doesn't like image path functions, does it? Using {PLACE_IMAGE (items/archery-target-right.png~FL(horiz)) 25 19} results in an error: "Preprocessor symbol PLACE_IMAGE expects 3 arguments, but has 4 argument"
20170129 13:25:22< Kwandulin> (1.12.6)
20170129 13:27:43-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170129 13:29:58-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 13:31:09< irker006> wesnoth: gfgtdf wesnoth:fix_25473 ccdb05ca130a / src/replay.cpp: fix 25473 https://github.com/wesnoth/wesnoth/commit/ccdb05ca130a3ffb68f8a40fc92e06bde62c4b31
20170129 13:32:09< irker006> wesnoth: gfgtdf wesnoth:fix_25473 32be2a2f27d2 / src/replay.hpp: fix 25473 https://github.com/wesnoth/wesnoth/commit/32be2a2f27d29cddca6770691a5ff9650e715a04
20170129 13:34:11< zookeeper> Kwandulin, if an argument contains parentheses, then i guess you need to use quotes
20170129 13:34:51< zookeeper> gfgtdf, isn't that just a case where the WML author needs to make sure that if they allow undo in a situation like that, it can't lead to OOS?
20170129 13:35:27< zookeeper> and they're free to do that any way they wish
20170129 13:36:31< Kwandulin> zookeeper: right
20170129 13:36:33< zookeeper> and if there was a [readd_event_on_undo] tag and they used that, wouldn't that just work the same as if they had simply had first_time_only=no?
20170129 13:37:02< zookeeper> hmh... okay, it wouldn't be the same.
20170129 13:37:48< zookeeper> so, currently i guess they would need to set a variable and have a [filter_condition] check that, and clear the variable in an [on_undo]?
20170129 13:38:20< zookeeper> which, to me, seems a reasonably simple solution in a situation like that
20170129 13:40:23-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20170129 13:47:49-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has left #wesnoth-dev []
20170129 13:48:07-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20170129 13:54:07-!- louis94 [~~louis94@199.35-245-81.adsl-dyn.isp.belgacom.be] has quit [Read error: Connection reset by peer]
20170129 13:57:53< irker006> wesnoth: David Mikos wesnoth:ping_test_disconnect_detect b32570869875 / src/ (4 files in 2 dirs): Initial ping disconnect detection implementation. https://github.com/wesnoth/wesnoth/commit/b3257086987504c42475f23c861f84a2b323cdde
20170129 14:00:09-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 14:00:11< gfgtdf> zookeeper: wey one coudl also do that with varibles, alternativeley one could wrap that [message] in a [unsynced] tag, but that would alos make that message show up in replays
20170129 14:05:36< zookeeper> [unsynced]... how new is that? can't find it in the wiki
20170129 14:06:08-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Ping timeout: 276 seconds]
20170129 14:09:59-!- travis-ci [~travis-ci@ec2-54-161-212-239.compute-1.amazonaws.com] has joined #wesnoth-dev
20170129 14:10:00< travis-ci> wesnoth/wesnoth#12583 (fix_25473 - ccdb05c : gfgtdf): The build failed.
20170129 14:10:00< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/196331259
20170129 14:10:00-!- travis-ci [~travis-ci@ec2-54-161-212-239.compute-1.amazonaws.com] has left #wesnoth-dev []
20170129 14:20:57< irker006> wesnoth: loonycyborg wesnoth:sql_prepared_statements 4917857eb999 / src/server/mysql_prepared_statement.ipp: Properly implement fetching strings from mysql https://github.com/wesnoth/wesnoth/commit/4917857eb99904d420b636982248733ec033e3e8
20170129 14:33:44-!- JyrkiVesterinen [~JyrkiVest@87-92-20-117.bb.dnainternet.fi] has quit [Quit: .]
20170129 14:42:50-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 14:42:52< gfgtdf> zookeeper: seems liek its missing in the wiki, is makes the enginge tread all nested command like the'y happen from an aunsynced event, in particular [message][options] are no longer synced across the network.
20170129 14:42:59< gfgtdf> zookeeper: my network connection kinda sucks here
20170129 14:43:13< zookeeper> yeah i noticed... :p
20170129 14:45:15< zookeeper> ok, but what happens if i have, say, a perfectly normal moveto event which simply has [message][option]s in an [unsynced] tag? the moveto event is fired on all clients, but what exactly happens with the contents of the [unsynced] tag? they are executed only on the client of the player who performed the move?
20170129 14:49:05-!- gfgtdf_ [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 14:50:20-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Ping timeout: 276 seconds]
20170129 14:50:30-!- gfgtdf_ is now known as gfgtdf
20170129 14:55:17-!- travis-ci [~travis-ci@ec2-54-221-31-255.compute-1.amazonaws.com] has joined #wesnoth-dev
20170129 14:55:18< travis-ci> wesnoth/wesnoth#12584 (fix_25473 - 32be2a2 : gfgtdf): The build passed.
20170129 14:55:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/196331518
20170129 14:55:18-!- travis-ci [~travis-ci@ec2-54-221-31-255.compute-1.amazonaws.com] has left #wesnoth-dev []
20170129 15:05:48-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has joined #wesnoth-dev
20170129 15:09:09-!- markus__ [~mjs-de@x4e31a4fa.dyn.telefonica.de] has joined #wesnoth-dev
20170129 15:10:09-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:7d43:eeb3:2da0:962c] has quit [Ping timeout: 255 seconds]
20170129 15:12:35-!- mjs-de [~mjs-de@x4db6ab27.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170129 15:12:52-!- gfgtdf_ [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 15:14:05-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170129 15:14:17-!- gfgtdf_ is now known as gfgtdf
20170129 15:15:43-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 15:20:02< gfgtdf> zookeeper: i think they are executed ann all clients
20170129 15:20:03-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has quit [Ping timeout: 255 seconds]
20170129 15:20:34-!- JyrkiVesterinen [~JyrkiVest@87-92-20-117.bb.dnainternet.fi] has joined #wesnoth-dev
20170129 15:25:14< gfgtdf> on
20170129 15:34:35-!- RatArmy_ [~ratarmy@om126212249033.14.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170129 15:36:19-!- travis-ci [~travis-ci@ec2-54-221-31-255.compute-1.amazonaws.com] has joined #wesnoth-dev
20170129 15:36:20< travis-ci> wesnoth/wesnoth#12585 (ping_test_disconnect_detect - b325708 : David Mikos): The build passed.
20170129 15:36:20< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/196336308
20170129 15:36:20-!- travis-ci [~travis-ci@ec2-54-221-31-255.compute-1.amazonaws.com] has left #wesnoth-dev []
20170129 15:38:43-!- Bonobo [~Bonobo@ppp118-210-252-236.bras1.adl4.internode.on.net] has quit [Ping timeout: 240 seconds]
20170129 15:44:12< irker006> wesnoth: Maximilian Fricke wesnoth:master 542873784ecf / src/ (3 files in 2 dirs): Fix a bug preventing quick replay when joining MP games https://github.com/wesnoth/wesnoth/commit/542873784ecf139c0ab07d555198324a1437c9c6
20170129 15:44:14< irker006> wesnoth: Maximilian Fricke wesnoth:master 9f62832b0e0a / changelog: Update changelog https://github.com/wesnoth/wesnoth/commit/9f62832b0e0a750b79896b0fb5f9eb1ccffac7d4
20170129 15:44:16< irker006> wesnoth: Jyrki Vesterinen wesnoth:master 19dec1aa5d68 / / (4 files in 3 dirs): Merge pull request #916 from madmax28/fix_mp_quick_replay https://github.com/wesnoth/wesnoth/commit/19dec1aa5d68020bd595f0a42ec7d71a74419019
20170129 15:50:05-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170129 15:52:39-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 15:56:09< gfgtdf> JyrkiVesterinen: did you test that pr before merging ?
20170129 15:57:15< JyrkiVesterinen> Only partially. I verified that it builds with Visual Studio, and read the code changes. However, I didn't test the bug fix itself.
20170129 15:58:02< JyrkiVesterinen> The only semantical change in the PR is here: https://github.com/wesnoth/wesnoth/pull/916/commits/542873784ecf139c0ab07d555198324a1437c9c6#diff-e977f06b760442b4a5869f07afe5ba32L367
20170129 15:58:21< gfgtdf> in prticular i cannot find the code that disbles 'skip replay' when the 'replay' is and the normal game begins
20170129 15:58:39< JyrkiVesterinen> Previously, the current_turn variable was always zero. Thus, the old line was a no-op.
20170129 15:59:30< JyrkiVesterinen> The new code sets skip_replay to true. It then propagates to the constructor of playsingle_controller.
20170129 16:00:19< gfgtdf> JyrkiVesterinen: yes but iirc it usually shoudl set skip_replay_ to fals as soon as the 'current'turn begind
20170129 16:01:44-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 16:01:56< gfgtdf> JyrkiVesterinen: that currently turn is zero might be onyl the case becase its not yet implemetned in the new gui2 mp lobby
20170129 16:03:26< gfgtdf> JyrkiVesterinen: generally it better not to merge prs that fast (this one was onyl open 4 hours), unless you are sure that you are the one that knows that particular code best. It is better give othre developers a chance to look at it.
20170129 16:06:06< zookeeper> gfgtdf, in that case i don't really understand what it means for the actions to be "unsynced"
20170129 16:06:42< JyrkiVesterinen> gfgtdf: Well, I'm not sure if we can really say that there are other developers left at this point...
20170129 16:06:43< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/pulls?q=is%3Apr+is%3Aclosed
20170129 16:07:15< JyrkiVesterinen> Excluding 909 and 916, the latest PR that was merged by someone other than the author was 908, which vultraz merged almost a month ago.
20170129 16:07:44< JyrkiVesterinen> I figured that 916 (and 917) would probably never be merged unless I merged it myself.
20170129 16:07:55< JyrkiVesterinen> And, personally, I prefer fast merging.
20170129 16:08:27< JyrkiVesterinen> (917 I intend to merge early next week, assuming that no one does it before me.)
20170129 16:09:43< irker006> wesnoth: Jyrki Vesterinen wesnoth:master a9e2b4ae46e7 / data/core/about.cfg: Add @madmax28 to credits https://github.com/wesnoth/wesnoth/commit/a9e2b4ae46e7be2cf02faf9b4afec64c636398a2
20170129 16:10:40< gfgtdf> zookeeper: well its makes the engine treat the code insoe liek it was unsynced
20170129 16:11:06< gfgtdf> zookeeper: asuime this event, http://pastebin.com/4582Me4B,  evne though ti has [allow_undo] you cannot undo it since the rand= above asks the serever for a random number which is sometihng that can never be undone
20170129 16:11:50< gfgtdf> zookeeper: btu it you put it in a [unsyced] it will to the random varible locally, this coudl cause OOS i that varible woudl be used to change that gamestate, but we dont so that, we only use it to show that message
20170129 16:12:05< gfgtdf> s/coudl/would
20170129 16:13:57< gfgtdf> JyrkiVesterinen: i am not sure how the lack of prs impes rthat noone than you woudl loook at prs
20170129 16:16:00< gfgtdf> JyrkiVesterinen: also, its just tham ome devlopers care more about oem aspects than the othjer,  i perosnalyl wouldn' looks at image or translation upate prs, but i woudl sure look at c++ code hnages on code tha i at lest partly wrote myself
20170129 16:17:06< gfgtdf> zookeeper: will do*, casue oos if*
20170129 16:19:12< zookeeper> gfgtdf, okay, makes sense in that context
20170129 16:19:13< gfgtdf> JyrkiVesterinen: and for prs that are made by a my a member of the dev team i woudl always expect that they do not want it to me merged by someone else but just gain some second opinion on it.
20170129 16:19:42< JyrkiVesterinen> gfgtdf: At least for my PRs, I prefer if someone else merges them.
20170129 16:19:54< JyrkiVesterinen> It merge them myself if no one else does it.
20170129 16:19:58< JyrkiVesterinen> *I
20170129 16:20:39< zookeeper> gfgtdf, but what else is affected by being unsynced, besides rand?
20170129 16:22:00< JyrkiVesterinen> vultraz: At some point you wondered if the "credits disappear at too high text size" issue is caused by the canvas size exceeding two billion pixels (2^31).
20170129 16:22:10< gfgtdf> zookeeper: [mesage] with [option]s for example
20170129 16:22:38< gfgtdf> zookeeper: the choice will no longer be synced along all clinets (and one made by the currnt client), but instead be doen on each client indepndently
20170129 16:22:41< JyrkiVesterinen> I just measured the canvas size. 857x32840. About 30 million pixels, nowhere near two billion.
20170129 16:23:31< gfgtdf> zookeeper: also [unit] calls the rnadom number generator for generatign traits, gender etc, if you for exampel want to creat e unit just to show it ina message it migth mage sense to use [unscyned9
20170129 16:24:25< gfgtdf> might make*
20170129 16:28:58< zookeeper> gfgtdf, right, right. maybe i got it now
20170129 16:31:18< zookeeper> gfgtdf, all the usecases seem pretty theoretical to me so i can't really say much about whether there is any need to provide authors with extra tools (such as [readd_event_on_undo]) to handle undo-related things.
20170129 16:31:54< gfgtdf> zookeeper: you mena the [unsyced] or [readd_event_on_undo] usecases?
20170129 16:33:22< zookeeper> well, i thought they were actually linked even though apparently they're not. but i guess i meant [readd_event_on_undo]
20170129 16:33:45< zookeeper> this is the kind of complicated stuff that i don't understand if i haven't ever used it myself
20170129 16:34:10< zookeeper> or rather, i understand it for about half an hour after it's been explained to me and then it vanishes from my mind
20170129 16:36:53< gfgtdf> zookeeper: you know whther dismissing units in the recall dialog can fore any events ?
20170129 16:37:16< gfgtdf> fire*
20170129 16:38:45< irker006> wesnoth: gfgtdf wesnoth:fix_25473 f09f2456dbc7 / src/actions/undo_move_action.cpp: fix 25473 3 https://github.com/wesnoth/wesnoth/commit/f09f2456dbc762992405774fda83a29e8d52e2ce
20170129 16:44:08< celmin|sleep> I'm around-ish as far as reviewing PRs is concerned.
20170129 16:45:05-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has quit [Remote host closed the connection]
20170129 16:45:29< irker006> wesnoth: pentarctagon wesnoth:master 420a9fa7c048 / data/lua/wml/message.lua: Fix the unit portrait being displayed with only second_image is provided https://github.com/wesnoth/wesnoth/commit/420a9fa7c048bbba1cc58cab1388188789230967
20170129 16:45:31< irker006> wesnoth: Celtic Minstrel wesnoth:master f00666feec53 / data/lua/wml/message.lua: Merge pull request #912 from Pentarctagon/only-second-image https://github.com/wesnoth/wesnoth/commit/f00666feec5398d82c732ef82bfb64ab54e4c844
20170129 16:45:47-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20170129 16:49:09-!- celmin|sleep is now known as celticminstrel
20170129 17:00:17-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 17:02:08< zookeeper> gfgtdf, it can't
20170129 17:02:50< zookeeper> might be good to have an event for that, though. i bet there's a lot of content that can be broken by dismissing units, because it's a feature i don't think a lot of people remember even exists :P
20170129 17:10:11< gfgtdf> zookeeper: hmm right, so i can't even prevent the user from dismissing certain units ?
20170129 17:10:20< zookeeper> yeah
20170129 17:10:49< zookeeper> there was some discussion a while back about the dismiss feature
20170129 17:11:13< gfgtdf> prevent dismissing of certain units seems lieka useful feature to  me, maybe just have a dsimissalbe=yes/no on [unit] or similar
20170129 17:12:33< gfgtdf> the reason why i'm talking about it is, the dismiss redo/undo code calls on_ondo/redo but they shoudl always be empty right ?
20170129 17:14:09< celticminstrel> Dismissing doesn't close the dialog, right? So it seems like it'd be hard to fire an event there.
20170129 17:15:40< zookeeper> this thread, i think: https://forums.wesnoth.org/viewtopic.php?f=12&t=43007
20170129 17:15:45< gfgtdf> celticminstrel: hmm not sure, i mean i see no reaosn why you couldn't for example have a event that bookkeeps the amount of dismissed units with a variable or similar.
20170129 17:17:51< celticminstrel> Not sure if I like that thread's idea. I guess it's not terrible at least.
20170129 17:18:58< zookeeper> gfgtdf, what dismiss redo/undo code? you can undo dismisses?
20170129 17:23:28< gfgtdf> zookeeper: appeareantly you can
20170129 17:26:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 255 seconds]
20170129 17:27:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170129 17:29:56-!- Kwandulin [~Miranda@p200300760F6EBF6EC8C9E53B07E0D490.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170129 17:30:18< zookeeper> gfgtdf, wow, that's weird :P
20170129 17:35:01-!- horrowind [~Icedove@2a02:810a:83c0:e4b4:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20170129 17:38:09-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has quit [Remote host closed the connection]
20170129 17:39:33-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 17:53:55-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has quit [Remote host closed the connection]
20170129 17:54:40-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170129 17:55:50-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170129 18:01:32-!- madmax28 [~max@xdsl-84-44-140-213.netcologne.de] has joined #wesnoth-dev
20170129 18:02:07-!- Kwandulin [~Miranda@p200300760F6EBF6EC9538768FC032F25.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170129 18:10:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds]
20170129 18:10:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170129 18:23:36< zookeeper> celticminstrel, why wouldn't you like it?
20170129 18:25:51< celticminstrel> I'm not sure...
20170129 18:26:38< madmax28> gfgtdf: hi, i'm the guy who send that PR you perviously discussed. i think you're right, it should turn off the quick replay mode once the current turn begins. unfortunately it's still broken now
20170129 18:29:41< celticminstrel> Feel free to open another PR then.
20170129 18:30:32< madmax28> will do
20170129 18:53:06< gfgtdf> madmax28: hoqw i think its was supposed to work is that here https://github.com/wesnoth/wesnoth/blob/1.13.6/src/game_initialization/multiplayer.cpp#L736 the game lobby knows what the current turn of that thta game is and that then here https://github.com/wesnoth/wesnoth/blob/1.13.6/src/playmp_controller.cpp#L337 the skip_replay_ is set to false when the that turn is reached
20170129 18:54:42< gfgtdf> madmax28: the later looks liek it had  bug where it complated mp_info_->skip_replay_until_turn  with 0 instead of turn()
20170129 18:55:16< gfgtdf> madmax28: and the first one seems just not to e implementd for the gui2 lobby version which replaces the older mp lobby
20170129 19:00:55< irker006> wesnoth: gfgtdf wesnoth:master 26d80bdb54e5 / src/ (actions/undo_move_action.cpp replay.cpp replay.hpp): fix OOS when redoing certain action with choices https://github.com/wesnoth/wesnoth/commit/26d80bdb54e5bbce702dc4e842f2ed65ac973e29
20170129 19:01:24< madmax28> gfgtdf thanks for the hints. yes the later version was dead code so i thought it was safe to remove but it shouldn't have been dead code :) i'll try to figure out where the earlier ui.current_turn got the turn info from
20170129 19:06:49-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 19:08:23-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Ping timeout: 276 seconds]
20170129 19:10:21-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has quit [Remote host closed the connection]
20170129 19:10:55-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 19:27:43-!- Kwandulin [~Miranda@p200300760F6EBF6EC9538768FC032F25.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170129 19:40:46-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has quit [Remote host closed the connection]
20170129 19:41:29-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 19:41:29-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has quit [Remote host closed the connection]
20170129 19:52:23-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 19:58:00< madmax28> gfgtdf i found the current turn in the lobby_main dialog. what's the right way to propagate information from the dialog to enter_wait_mode? i saw that previously a static function playmp_controller was called by the dialog directly, but i'd like to avoid that
20170129 20:14:52< zookeeper> gfgtdf, does the support for [+help] really have anything to do with gui1/2 or the markup syntax? i don't know the code but it sounds a bit weird if changing the latter things would somehow affect how the former would be implemented.
20170129 20:27:18-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has quit [Remote host closed the connection]
20170129 20:27:45-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 20:38:20-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 20:38:35-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has quit [Remote host closed the connection]
20170129 20:39:57< gfgtdf> zookeeper: well yes, i mena in the [help] goes [topic] with text=...some marked-up string...   . If we for example implement [help] now and change the markup syntax later all older wml code that uses [help] will be invalid
20170129 20:40:23< gfgtdf> all older umc wml code
20170129 20:40:56< celticminstrel> The markup syntax is likely to change, yeah... but not guaranteed, I guess.
20170129 20:41:26< celticminstrel> The markup syntax is somehow WML.
20170129 20:41:37< celticminstrel> Something like WML-attributed text.
20170129 20:41:43< celticminstrel> It's a bit weird.
20170129 20:41:53< zookeeper> gfgtdf, but how is that a problem?
20170129 20:42:37< celticminstrel> (Mind you, even if the markup syntax is changed, surely both syntaxes would be supported at first?)
20170129 20:42:46< gfgtdf> zookeeper: well people poftne complain when their code that then their code suddently doesnt work anymore
20170129 20:43:05< gfgtdf> celticminstrel: as long as there is no way to use that syntax from umc there is no reaosn to support both syntaxes
20170129 20:43:16< celticminstrel> But there is a way, isn't there?
20170129 20:43:27< celticminstrel> Can't UMC add arbitrarily many new help topics>
20170129 20:43:31< gfgtdf> celticminstrel: not that i know of.
20170129 20:43:48< celticminstrel> Hmm. I thought they could. Someone should try it and see.
20170129 20:43:51< zookeeper> gfgtdf, i bet they complain less than when they can't do anything at all, especially if it's made clear that the markup is likely to change too.
20170129 20:44:36< zookeeper> no one's gonna think that it's better that they can't make any custom help topics than that they can but have to update their markup at some point
20170129 20:50:17-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 20:52:57-!- Coffee_irc [~david@ppp118-210-252-236.bras1.adl4.internode.on.net] has quit [Quit: Konversation terminated!]
20170129 21:00:21-!- RatArmy_ [~ratarmy@om126211124255.13.openmobile.ne.jp] has joined #wesnoth-dev
20170129 21:26:02-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has quit [Remote host closed the connection]
20170129 21:36:31-!- gfgtdf_ [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 21:37:35-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20170129 21:37:41-!- gfgtdf_ is now known as gfgtdf
20170129 21:46:43-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20170129 22:01:05-!- irker006 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170129 22:06:45-!- JyrkiVesterinen [~JyrkiVest@87-92-20-117.bb.dnainternet.fi] has quit [Quit: .]
20170129 22:07:08-!- atarocch [~atarocch@93.56.160.28] has quit [Remote host closed the connection]
20170129 22:07:16-!- Appleman1234 [~Appleman1@KD106161230008.au-net.ne.jp] has quit [Ping timeout: 255 seconds]
20170129 22:15:09-!- Appleman1234 [~Appleman1@KD106161233107.au-net.ne.jp] has joined #wesnoth-dev
20170129 22:15:11-!- RatArmy_ [~ratarmy@om126211124255.13.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170129 22:15:59-!- madmax28 [~max@xdsl-84-44-140-213.netcologne.de] has quit [Quit: Leaving]
20170129 22:16:01-!- markus__ [~mjs-de@x4e31a4fa.dyn.telefonica.de] has quit [Remote host closed the connection]
20170129 22:23:41-!- crossbreed [~crossbree@xdsl-84-44-140-213.netcologne.de] has joined #wesnoth-dev
20170129 22:24:10-!- crossbreed [~crossbree@xdsl-84-44-140-213.netcologne.de] has left #wesnoth-dev []
20170129 22:29:02-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has joined #wesnoth-dev
20170129 22:32:48-!- gfgtdf [~chatzilla@x4e36a75f.dyn.telefonica.de] has quit [Client Quit]
20170129 22:36:17-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Read error: Connection reset by peer]
20170129 22:36:23-!- bumba [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20170129 22:37:49-!- RatArmy_ [~ratarmy@om126211124255.13.openmobile.ne.jp] has joined #wesnoth-dev
20170129 22:41:05-!- Bhoren [~Bhoren_wi@LAubervilliers-656-1-270-96.w193-248.abo.wanadoo.fr] has quit [Read error: Connection reset by peer]
20170129 22:43:16-!- crossbreed [~crossbree@xdsl-84-44-140-213.netcologne.de] has joined #wesnoth-dev
20170129 22:43:28-!- crossbreed [~crossbree@xdsl-84-44-140-213.netcologne.de] has quit [Remote host closed the connection]
20170129 22:47:51-!- crossbreed [~crossbree@xdsl-84-44-140-213.netcologne.de] has joined #wesnoth-dev
20170129 22:48:22-!- crossbreed [~crossbree@xdsl-84-44-140-213.netcologne.de] has quit [Client Quit]
20170129 22:48:45-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20170129 22:51:37-!- Duthlet [~Duthlet@dslb-188-105-120-162.188.105.pools.vodafone-ip.de] has quit [Quit: leaving]
20170129 22:53:47-!- Bonobo [~Bonobo@ppp118-210-252-236.bras1.adl4.internode.on.net] has joined #wesnoth-dev
20170129 22:56:37-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:749f:3392:c59:55d] has joined #wesnoth-dev
20170129 22:59:57-!- prkc [~prkc@46.166.190.212] has quit [Quit: Leaving]
20170129 23:38:10-!- RatArmy_ [~ratarmy@om126211124255.13.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170129 23:54:15-!- RatArmy_ [~ratarmy@133.15.175.65] has joined #wesnoth-dev
--- Log closed Mon Jan 30 00:00:09 2017