--- Log opened Sat Feb 04 00:00:57 2017
20170204 00:16:04< celticminstrel> gfgtdf: Well, github is not the only option; JIRA and redmine were also proposed, and at least one of them is no less viable than github.
20170204 00:17:28< celticminstrel> JIRA has allowance for open-source projects, though I could imagine it putting off a few people who are zealous about free software. Redmine would require someone to host it.
20170204 00:22:26-!- travis-ci [~travis-ci@ec2-54-161-161-30.compute-1.amazonaws.com] has joined #wesnoth-dev
20170204 00:22:27< travis-ci> wesnoth/wesnoth#12613 (master - 733e2a2 : Jyrki Vesterinen): The build passed.
20170204 00:22:27< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/198121019
20170204 00:22:27-!- travis-ci [~travis-ci@ec2-54-161-161-30.compute-1.amazonaws.com] has left #wesnoth-dev []
20170204 00:34:57< gfgtdf> celticminstrel: hmm yes thats why i said "unless someone puts time invetigating"
20170204 00:35:56< celticminstrel> Maybe the person running Jenkins could also run redmine. (I dunno.) I think JIRA was considered the best option by certain people and github was frowned upon as lacking essential features.
20170204 00:37:07< gfgtdf> celticminstrel: hmm yes you afaik cannot upload aribtary files (especialyl savefiles) but i can zip them an then upload, another lacking feature is creatign issues without creating an account
20170204 00:37:49< gfgtdf> but you* can zip them
20170204 00:38:37< celticminstrel> Save files are typically already zipped.
20170204 00:39:34< gfgtdf> celticminstrel: well thea are alreqady in .gz format, sems useless to pack tthose ina  .zip file . afaik github only accepts .zip extension
20170204 00:39:57< gfgtdf> nut sure whterh that's sitll the case though
20170204 00:40:31< gfgtdf> hmm seems i was wrong, it supportzs .gz too
20170204 00:41:07< gfgtdf> still the issue hold for peole who use .bz2 comrepssion :)
20170204 00:43:46-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 00:43:46< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Release Jyrki Vesterinen 733e2a2: Fix unit tests Succeeded
20170204 00:43:46< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-196
20170204 00:43:50-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 01:05:41-!- Bonobo [~Bonobo@ppp118-210-252-236.bras1.adl4.internode.on.net] has joined #wesnoth-dev
20170204 01:09:20-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 01:09:20< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Debug Jyrki Vesterinen 733e2a2: Fix unit tests Succeeded
20170204 01:09:20< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-196
20170204 01:09:24-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 01:17:22-!- irker287 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170204 01:18:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170204 01:19:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170204 01:23:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170204 01:31:34-!- travis-ci [~travis-ci@ec2-23-20-12-213.compute-1.amazonaws.com] has joined #wesnoth-dev
20170204 01:31:35< travis-ci> wesnoth/wesnoth#12614 (addon_install_dependencies_n - ea4b003 : Jyrki Vesterinen): The build passed.
20170204 01:31:35< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/198127278
20170204 01:31:35-!- travis-ci [~travis-ci@ec2-23-20-12-213.compute-1.amazonaws.com] has left #wesnoth-dev []
20170204 01:41:04-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 01:41:04< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Release Jyrki Vesterinen 733e2a2: Fix unit tests Succeeded
20170204 01:41:04< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-199
20170204 01:41:08-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 01:41:38-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20170204 01:42:58-!- Aginor [~andreas@unaffiliated/aginor] has quit [Ping timeout: 264 seconds]
20170204 01:45:43-!- Aginor [~andreas@apollo.alternating.net] has joined #wesnoth-dev
20170204 01:45:43-!- Aginor [~andreas@apollo.alternating.net] has quit [Changing host]
20170204 01:45:43-!- Aginor [~andreas@unaffiliated/aginor] has joined #wesnoth-dev
20170204 01:51:59-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170204 01:52:00-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170204 01:56:51-!- stikonas_ is now known as stikonas
20170204 02:00:26-!- gfgtdf [~chatzilla@x4e368fe4.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 51.0.1/20170125094131]]
20170204 02:05:33-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 02:05:33< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Debug Jyrki Vesterinen 733e2a2: Fix unit tests Succeeded
20170204 02:05:33< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-199
20170204 02:05:37-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 02:45:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170204 02:48:54-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 03:32:09-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 03:32:47-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 03:36:58-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Ping timeout: 255 seconds]
20170204 03:46:12-!- gfgtdf [~chatzilla@x4e36a6e5.dyn.telefonica.de] has joined #wesnoth-dev
20170204 03:46:52< gfgtdf> loonycyborg: you think it'd be ratehr easy to implement some communication bewtween the addon and the mp server so that the mp server can wanrn users if they host a game with an outdated version ?
20170204 03:48:33-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 03:48:58< gfgtdf> do you*
20170204 03:51:52-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 03:52:24-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 03:56:46-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Ping timeout: 255 seconds]
20170204 04:05:47-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 04:05:49-!- gfgtdf [~chatzilla@x4e36a6e5.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 51.0.1/20170125094131]]
20170204 04:42:43-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 04:57:35-!- Appleman1234 [~Appleman1@KD106161229077.au-net.ne.jp] has quit [Ping timeout: 240 seconds]
20170204 05:45:22-!- Bonobo [~Bonobo@ppp118-210-252-236.bras1.adl4.internode.on.net] has quit [Read error: Connection reset by peer]
20170204 05:45:51-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 05:49:08-!- JyrkiVesterinen [~JyrkiVest@87-100-233-147.bb.dnainternet.fi] has joined #wesnoth-dev
20170204 05:50:28-!- Bonobo [~Bonobo@ppp118-210-252-236.bras1.adl4.internode.on.net] has joined #wesnoth-dev
20170204 05:50:37-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Ping timeout: 255 seconds]
20170204 05:53:14-!- celticminstrel is now known as celmin|sleep
20170204 06:00:45-!- Kwandulin [~Miranda@p200300760F6EBFC305B1FEDEC24791D7.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170204 06:22:46-!- Appleman1234 [~Appleman1@KD106161218167.au-net.ne.jp] has joined #wesnoth-dev
20170204 06:47:33-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 06:53:10-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Ping timeout: 255 seconds]
20170204 07:49:42-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20170204 07:51:08-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 245 seconds]
20170204 07:51:08-!- wedge010 is now known as wedge009
20170204 07:52:43-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170204 07:52:43-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20170204 08:34:17-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20170204 08:37:29-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20170204 08:40:08-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20170204 08:40:08-!- wedge010 is now known as wedge009
20170204 08:42:28-!- Duthlet [~Duthlet@dslb-188-105-120-162.188.105.pools.vodafone-ip.de] has joined #wesnoth-dev
20170204 08:43:30-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 08:43:30< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Release Jyrki Vesterinen 733e2a2: Fix unit tests Succeeded
20170204 08:43:30< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-197
20170204 08:43:35-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 08:44:20< loonycyborg> gfgtdf: outdated version of what?
20170204 08:44:25< loonycyborg> some other addon?
20170204 08:44:54< loonycyborg> It's not the way things work currently
20170204 08:45:07< loonycyborg> clients are responsible for stuff like that
20170204 08:46:31-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170204 09:05:39-!- Kwandulin [~Miranda@p200300760F6EBFC305B1FEDEC24791D7.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170204 09:07:36-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 09:07:36< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Debug Jyrki Vesterinen 733e2a2: Fix unit tests Succeeded
20170204 09:07:36< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-197
20170204 09:07:40-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 09:21:43-!- irker467 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170204 09:21:43< irker467> wesnoth: Jyrki Vesterinen wesnoth:master da8210779f21 / src/ (4 files in 2 dirs): Move add-on dependency management to the add-on client https://github.com/wesnoth/wesnoth/commit/da8210779f21c48872b287447c7d1f034e60d01a
20170204 09:37:13-!- JyrkiVesterinen [~JyrkiVest@87-100-233-147.bb.dnainternet.fi] has quit [Quit: .]
20170204 09:41:05-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 09:41:05< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Release Jyrki Vesterinen 733e2a2: Fix unit tests Succeeded
20170204 09:41:05< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-200
20170204 09:41:09-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 09:49:04-!- Kwandulin [~Miranda@p200300760F6EBFC3EDE3C081D57FA78C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170204 10:05:30-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 10:05:30< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Debug Jyrki Vesterinen 733e2a2: Fix unit tests Succeeded
20170204 10:05:30< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-200
20170204 10:05:34-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 10:39:12< irker467> wesnoth: loonycyborg wesnoth:sql_prepared_statements e549a7c42a89 / src/server/ (forum_user_handler.cpp mysql_prepared_statement.ipp): Do probe queries without logging an error for each user not found https://github.com/wesnoth/wesnoth/commit/e549a7c42a89d226bbe5ee8a718eb472149efca0
20170204 10:50:10-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 10:54:49-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Ping timeout: 255 seconds]
20170204 10:59:28-!- Bonobo [~Bonobo@ppp118-210-252-236.bras1.adl4.internode.on.net] has quit [Ping timeout: 240 seconds]
20170204 11:01:25-!- Bonobo [~Bonobo@2001:44b8:254:3200:8cb:9777:e724:ccd5] has joined #wesnoth-dev
20170204 11:05:50-!- UnwiseOwl [~UnwiseOwl@81.168.19.242] has joined #wesnoth-dev
20170204 11:06:11-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20170204 11:07:05-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20170204 11:07:05-!- wedge010 is now known as wedge009
20170204 11:15:51< irker467> wesnoth: Nils Kneuper wesnoth:master ae46637a0423 / / (9 files in 8 dirs): updated Scottish Gaelic translation https://github.com/wesnoth/wesnoth/commit/ae46637a04234292820cf0239200eb8baac01a63
20170204 11:35:01-!- UnwiseOwl [~UnwiseOwl@81.168.19.242] has quit [Ping timeout: 255 seconds]
20170204 12:12:20-!- Kwandulin [~Miranda@p200300760F6EBFC3EDE3C081D57FA78C.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170204 12:17:20-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170204 12:33:10< irker467> wesnoth: loonycyborg wesnoth:sql_prepared_statements 41c0fc242e14 / src/server/forum_user_handler.cpp: Screen column and table names in sql with backticks for safety https://github.com/wesnoth/wesnoth/commit/41c0fc242e148ddc98127209446111fe06835227
20170204 12:44:05-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Remote host closed the connection]
20170204 12:44:42-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20170204 12:59:37-!- Bonobo [~Bonobo@2001:44b8:254:3200:8cb:9777:e724:ccd5] has quit [Ping timeout: 255 seconds]
20170204 13:20:32-!- Kwandulin [~Miranda@p200300760F6EBFC3CC3C3518EC13CE96.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170204 13:31:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170204 13:52:13-!- gfgtdf [~chatzilla@x4e36a6e5.dyn.telefonica.de] has joined #wesnoth-dev
20170204 13:54:45< gfgtdf> loonycyborg: well if you want to start an mp game with ageless era 4.10 it' be better to give a wanring since it'll usualyl mena that other players can't enter
20170204 13:55:15< gfgtdf> loonycyborg: ye si know thats currently the the clients are 'respoonsible' that's yb im asking how hard it'D be to change that
20170204 14:06:30< gfgtdf> loonycyborg: afaik connecting to the addon server to downaload teh addons data can take a while if the list is long (at lest thats what i assumed since the addon dialog takes a often quite a logn time to load but maybe its also a gui problem). But themp server coudl just cache att the addon version and keep an open connection to the addon server for updates.
20170204 14:08:14-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170204 14:11:37< loonycyborg> gfgtdf: It might be very hard because currently wesnothd has nearly no knowledge of clientside stuff
20170204 14:12:09< loonycyborg> and it might be hard to reuse clientside code without dropping simple_wml
20170204 14:13:37< loonycyborg> also I still don't understand your usecase
20170204 14:13:49< loonycyborg> doesn'
20170204 14:14:08< loonycyborg> don't clients have enough info to ensure compatibility?
20170204 14:15:51< Ravana_> 1.13 should already have addon_min_version= for that
20170204 14:16:14-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 14:17:36< gfgtdf> loonycyborg: well they'd need to asks for that information on the server, the client only has it current version of a addon and min_version tpo cehck whetehr an other version os compatible
20170204 14:18:54< gfgtdf> loonycyborg: this is used, so that for exmaple when a client connects to a game, it can check whetehr its compatible and if not automatically donaload a newer version form the addon server
20170204 14:19:31< gfgtdf> loonycyborg: but this won't works so well when the host uses an outdated version that is incomtible with the versions by other player or on the addon server
20170204 14:20:35< gfgtdf> loonycyborg: connectign players just cannot do anything (connect, update) and the hosts gets no notification why that is
20170204 14:20:52< loonycyborg> then why involve addon server? you only need to ensure that mp era/campaigns have same version
20170204 14:21:17-!- UnwiseOwl [~UnwiseOwl@81.168.19.242] has joined #wesnoth-dev
20170204 14:22:20< gfgtdf> loonycyborg: well yes the client ensures that already, but if they dont have the same version they just cannot play together. THe host will open game and noone will enter, then the host player will likely give up starting  weesnoth game soon.
20170204 14:22:21< loonycyborg> so only issue here I guess is that there's no standard way for clients to query each others about their versions of addons
20170204 14:23:08< gfgtdf> loonycyborg: currently the hosts sens his versions to the other players and those then check whether its compatible.
20170204 14:24:09< loonycyborg> then what's the issue?
20170204 14:24:14< loonycyborg> error message is unclear?
20170204 14:24:48< loonycyborg> I think it still can be made on clientside
20170204 14:25:09< gfgtdf> loonycyborg: no err message at all, the host just doesn't know why there are no players entering his game
20170204 14:25:34< loonycyborg> I mean for other players
20170204 14:25:57< loonycyborg> how exactly is this version checking is done?
20170204 14:27:10< gfgtdf> loonycyborg: hosts gamestate contains all adon version and the clients check it, if they dont macth teh plaers are given an erormessge an an option to connect to the adon server to download the newest version fo that addon
20170204 14:28:52< loonycyborg> so what do you want server to do? check version info too against what addon server has?
20170204 14:29:35< gfgtdf> loonycyborg: yes and gibe the hosts a wanring outdated
20170204 14:30:14< loonycyborg> but it still seems kinda assymetric
20170204 14:30:34< loonycyborg> for non-hosts client can check versions and trigger updates
20170204 14:30:45< loonycyborg> while for hosts server must do it
20170204 14:30:50< loonycyborg> for some reason
20170204 14:34:02-!- JyrkiVesterinen [~JyrkiVest@87-100-233-147.bb.dnainternet.fi] has joined #wesnoth-dev
20170204 14:36:40< gfgtdf> loonycyborg: yes becasue the cleints have all infomaction (the hosts version and the thris version), whoel the hosts when he starts hosting has onyl his own version. Even with my suggestion that server informations he can only increase his chances of hving versiosn matching, not guaranteeing.
20170204 14:37:03< loonycyborg> not true
20170204 14:37:11< loonycyborg> host knows his own version and addon version
20170204 14:37:20< loonycyborg> addon server version
20170204 14:37:33< loonycyborg> I mean client can check addon server too
20170204 14:37:57-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 14:42:52< Ravana_> My vision of this: A has addon v 1, B has addon v 2. Addon server has v 3. B hosts. A tries to join, gets notice its old, updates to v 3. A tries to join, B gets notice that he has old.
20170204 14:45:18-!- celmin|sleep is now known as celticminstrel
20170204 14:46:28-!- UnwiseOwl [~UnwiseOwl@81.168.19.242] has quit [Ping timeout: 240 seconds]
20170204 14:47:42< loonycyborg> if client checks addon server before hosting then hoster will be always warned that he's hosting old version
20170204 14:48:13< loonycyborg> unless it was updated while game was in progress that is :P
20170204 15:03:38-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 15:06:42-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 15:09:39< gfgtdf> loonycyborg: yes the host can connect to the addon server too, but i wonder whther that migth be to slow considering ho long the addon manager dialog usually takes to open when there are many addons.
20170204 15:10:00< loonycyborg> it might be complicated to do on server too
20170204 15:10:31< loonycyborg> firstly it's more admin work to keep track of which addon server which wesnothd should connect to
20170204 15:10:38< loonycyborg> second even if you cache addon list
20170204 15:10:46< loonycyborg> you need to update it at some point
20170204 15:11:08< loonycyborg> since people still can upload new addons there
20170204 15:11:19< gfgtdf> loonycyborg: hmm yes but the wesnothd server coudl just keep an open connection to the addon server so that it gets notified with updated
20170204 15:11:50< gfgtdf> versions
20170204 15:25:16-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 255 seconds]
20170204 15:31:14-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev
20170204 15:33:16-!- irker467 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170204 15:38:26< gfgtdf> sen: mattsc
20170204 15:38:30< gfgtdf> seen:mattsc
20170204 15:46:02< gfgtdf> mattsc: i am thinking about deprcating ai.syncec_command with  a less dynamic function, that requires you to explicitly register a function first, and then call it with ai.synced_command("functionname", args)
20170204 15:47:20< gfgtdf> mattsc: any opiniition on that ? 
20170204 15:49:18< gfgtdf> mattsc: so that for example https://github.com/wesnoth/wesnoth/blob/1.13.6/data/campaigns/Son_Of_The_Black_Eye/ai/ca_transport_S6.lua#L117 woudl need to be replaced with ai.synced_command("set_landed", {x = best_unit.x, y = best_unit.y}) together with some [register_command] name = ""set_landed", code = .... earlier
20170204 15:49:34< gfgtdf> mattsc: not sure yet what that 'eariler' sould be eactly
20170204 16:31:31-!- DeFender1031 [~DeFender1@dsl217-132-26-157.bb.netvision.net.il] has joined #wesnoth-dev
20170204 16:37:21-!- Bhoren [~Bhoren_wi@lns-bzn-20-82-64-3-181.adsl.proxad.net] has joined #wesnoth-dev
20170204 16:38:22-!- Kwandulin [~Miranda@p200300760F6EBFC3CC3C3518EC13CE96.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170204 16:42:14-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 16:42:14< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Release Nils Kneuper ae46637: updated Scottish Gaelic translation Succeeded
20170204 16:42:14< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-198
20170204 16:42:18-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 16:49:37-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 17:06:41-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 17:06:41< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Debug Nils Kneuper ae46637: updated Scottish Gaelic translation Succeeded
20170204 17:06:41< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-198
20170204 17:06:45-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 17:10:56-!- Kwandulin [~Miranda@p200300760F6EBFC3C99E9F91011D1C22.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170204 17:32:11-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 17:40:12-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 17:40:12< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Release Nils Kneuper ae46637: updated Scottish Gaelic translation Succeeded
20170204 17:40:12< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-201
20170204 17:40:16-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 17:41:01-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 17:54:03< EliDupree2> sigh, looks like my latest EoHS release caused a crash for 1.12.5 users
20170204 17:55:31< EliDupree2> I wish I could get a lua backtrace in the case of crashes. As it is, I don't even have any idea which part of my code triggered it
20170204 17:58:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170204 17:59:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170204 17:59:32-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Read error: Connection reset by peer]
20170204 18:02:34-!- UnwiseOwl [~UnwiseOwl@81.168.19.242] has joined #wesnoth-dev
20170204 18:05:53-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20170204 18:05:53< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Debug Nils Kneuper ae46637: updated Scottish Gaelic translation Succeeded
20170204 18:05:53< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-201
20170204 18:05:57-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20170204 18:06:31< UnwiseOwl> z
20170204 18:07:49< EliDupree2> The report looks like an assertion failure in boost variant. I searched the wesnoth bug tracker for "variant", but didn't find anything related. Strange, I would have thought it was a bug that was found and fixed between 1.12.5 and 1.12.6
20170204 18:23:29< gfgtdf> EliDupree2: you mean the one meantione din your forum thread ?
20170204 18:24:05< EliDupree2> yes
20170204 18:24:28< gfgtdf> EliDupree2: and you coudl repdece with with wesnoth 1.12.5 and wensoth 1.12.6 ?
20170204 18:24:39< EliDupree2> no
20170204 18:24:52< gfgtdf> EliDupree2: coudl you reproduce it at all ?
20170204 18:25:09< EliDupree2> no, two 1.12.5 users had it
20170204 18:25:18< EliDupree2> I have 1.12.4 nd 1.12.6 installed
20170204 18:25:21< EliDupree2> neither had it
20170204 18:27:01< gfgtdf> if neigher 1.12.6 not 1.12.4 has it i think its rarhre unlikeley that its casues by wesntoh version
20170204 18:27:17< gfgtdf> EliDupree2: also the number of commits in the c++ yoruce between 1.12.5 adn 1.12.6 is quite limited
20170204 18:28:16< gfgtdf> hmm, maybe those people buidl wesnoth with a different boost version ?
20170204 18:28:25< gfgtdf> EliDupree2: what boost bersion do you use ?
20170204 18:28:54< EliDupree2> hrm
20170204 18:30:08< EliDupree2> I think 1.62
20170204 18:32:06< gfgtdf> EliDupree2: that assert was from visitation_impl.hpp was removed in https://github.com/boostorg/variant/commit/0367512bc796f6e379e42c6945adf828aa4bcc5f which is betwen 1.55 and 1.62
20170204 18:32:16< EliDupree2> haha
20170204 18:32:56< EliDupree2> So… Does that mean all of 1.12 branch actually relies on a newer boost version?
20170204 18:33:51< gfgtdf> EliDupree2: hmm no we don't know what teh actuall errir is yet, we just know why you don'T get it, it still possible that there is an erro in wensoth code that somehow just doenst show for you.
20170204 18:34:22< gfgtdf> EliDupree2: i mean even though that asser was rmeoved the comment in the boost code still says '//should never be here at runtime!'
20170204 18:34:35< EliDupree2> haha what
20170204 18:34:57< gfgtdf> s/rmeoved/removed
20170204 18:36:01< gfgtdf> i guess without a stacktrace we won't find out
20170204 18:39:03< EliDupree2> Okay who wants to do the work of building wesnoth with boost 1.55 to debug it :/
20170204 18:39:25-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 18:40:00< gfgtdf> hmm noone i gues
20170204 18:42:31-!- UnwiseOwl [~UnwiseOwl@81.168.19.242] has quit [Ping timeout: 255 seconds]
20170204 19:15:18< celticminstrel> gfgtdf: Why is ai.synced_command a function at all? Why not a table similar to wesnoth.wml_actions?
20170204 19:15:59< gfgtdf> celticminstrel: sycned_command is a function to isue synced commands from the (unsycned) ai code.
20170204 19:16:17< gfgtdf> celticminstrel: inliek ai.move ai.attack etc. oit can isue arbitary lua code
20170204 19:16:19< gfgtdf> unlike*
20170204 19:16:53< celticminstrel> That doesn't answer my question.
20170204 19:17:28< gfgtdf> celticminstrel: sry i dontunderstand your question why shoudl it be a table ?
20170204 19:18:38< celticminstrel> Isn't it nicer to write ai.synced_commands.set_landed{x = best_unit.x, y = best_unit.y} rather than ai.synced_command("set_landed", {x = best_unit.x, best_unit.y}) ?
20170204 19:19:12< celticminstrel> If you've got a function where the first parameter is a string specifying what to do, why is it a function and not a table?
20170204 19:20:01< gfgtdf> celticminstrel: hmm no the point is that currently the first parmater is no an identifer string, but lua code stirng e.g ai.synced_command("set_landed(" .. best_unit.x .. "," ..  best_unit.y")")
20170204 19:20:36< celticminstrel> Sure.
20170204 19:20:48-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 19:20:56< celticminstrel> But my point is that it makes more sense to turn it into a table rather than changing the parameters.
20170204 19:21:40< celticminstrel> Also, why the heck is it a code string instead of a function?
20170204 19:21:56< gfgtdf> celticminstrel: because it sense that string to the netowrk to be executed on all clients
20170204 19:22:09< celticminstrel> Hmm, I guess maybe because closures could cause problems with syncing...
20170204 19:22:22< celticminstrel> ^synching
20170204 19:23:21< celticminstrel> I mean, it's probably theoretically possible to transmit Lua bytecode across the network, but probably far easier to just transmit the plaintext code.
20170204 19:23:31< gfgtdf> celticminstrel: well i dotn really care how the exact syntax will be later (table or addintion first parameter). My question was more whther there is some problem wit requiting the code to register the function from synced code.
20170204 19:23:39< gfgtdf> additional*
20170204 19:23:56< celticminstrel> Ah.
20170204 19:25:41< celticminstrel> Seems like it'd be a little confusing if you're required to place AI support code in a [lua] tag or similar.
20170204 19:25:48< celticminstrel> ie, outside of the general AI area.
20170204 19:27:31< EliDupree2> Just got an assertion failure in boost 1.61 in wesnoth 1.12.6
20170204 19:28:02< gfgtdf> celticminstrel: we coudl allot it somhere in the starting [ai] block, not sure. Just something that is part of the starting [scenario]
20170204 19:28:13< EliDupree2> boost_1_61_0/boost/variant/de.../forced...urn.hpp line 39 expression false
20170204 19:28:39< celticminstrel> Well, maybe then.
20170204 19:29:03< celticminstrel> If you had to do it in the [engine] for example, that doesn't seem like it'd be a problem. (Though substituting the engine is a little tricky ATM.)
20170204 19:29:39< gfgtdf> EliDupree2: you have a stacktrace ?
20170204 19:29:45< EliDupree2> no :(
20170204 19:29:54< EliDupree2> how to get?
20170204 19:30:03< EliDupree2> oh I could gdb it
20170204 19:34:56< EliDupree2> backtrace http://pastebin.com/3FvE1w5Z
20170204 19:36:48< gfgtdf> EliDupree2: ok thx
20170204 19:37:11< gfgtdf> EliDupree2: ok this somhow point to  [set_variable]
20170204 19:37:30< EliDupree2> Yeah, I figured. I expected it to be something more sophisticated like graphics LOL
20170204 19:38:26< gfgtdf> hm ye same here
20170204 19:39:20< EliDupree2> Let's see, I could dump all set_variable call data so that I can determine what exact inputs caused the bug
20170204 19:42:49-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 19:46:54< gfgtdf> hmm yes but the actual assertion failure comes from config::attribute_value::operator=(long long) () which is something so commonly used that its quite hard to belielbe that there is a bug in it.
20170204 19:47:15< gfgtdf> so it is possible that soeming went wrping eariler (memery corruoption in the worst case)
20170204 19:47:23< EliDupree2> ,Darn it, I didn't get much information because apparently the inputs to wesnoth.wml_actions.whatever are actually user data rather than tables
20170204 19:48:05< EliDupree2> However I DID discover that the last [set_variable] invocation before the crash was a rand=
20170204 19:48:43< gfgtdf> EliDupree2: yes those inputs are vconfig userdta, but they can be acces with asd.value like tables. also teh have a __literal filed which converts them to tables
20170204 19:48:56< EliDupree2> cool
20170204 19:49:35< EliDupree2> Specifically the first rand= in a menu_item event
20170204 19:50:09< gfgtdf> EliDupree2: you mean 'rand=""' e.g eith an empoty string or just generaly with an rand attribute ?
20170204 19:50:10< EliDupree2> So it would be one that did networking. And as far as I can tell, this bug does NOT happen in local games, which points further fingers at the networking
20170204 19:50:14< EliDupree2> the latter
20170204 19:50:52< EliDupree2> waaaaait
20170204 19:50:56< EliDupree2> ffs
20170204 19:51:18< EliDupree2> oh nvm
20170204 19:52:17< gfgtdf> ?
20170204 19:52:32< EliDupree2> Wait, maybe it's not the NETWORKING per se – maybe it's the fact that it yields to the UI, allowing it to invoke lua theme items
20170204 19:53:21< EliDupree2> Meaning that it could be in the middle of a set_variable when it does another operation on the variables, possibly resulting in memory corruption
20170204 19:53:42< EliDupree2> That also explains why the bug isn't 100% reliable – it's a race condition!
20170204 19:55:10< gfgtdf> EliDupree2: hmm afaiuk the onyl multithreadinf stuff is the loadingscrren (new in 1.13) and the openmp unit drawing
20170204 19:55:39< EliDupree2>  multithreading isn't necessary to cause this problem
20170204 19:56:05< EliDupree2> All that had to happen was for the developers to write code that didn't consider the case of operations being nested
20170204 19:56:30< gfgtdf> i think in theory the unti drawing code can call wml filters...
20170204 19:56:37< gfgtdf> what do you mean by nested ?
20170204 19:56:53< EliDupree2> I mean, I could call set_variable during another set_variable
20170204 19:56:57-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 19:57:15< EliDupree2> Nested in the sense of "one inside the other"
20170204 19:58:47< gfgtdf> EliDupree2: how youl that be possible? afaik set_varoible doesnt allow you to execute code in it.
20170204 19:59:16< EliDupree2> With rand= it does, while it is waiting for the network
20170204 19:59:30< EliDupree2> Theme items can be called during that time, which can invoke arbitrary lua
20170204 19:59:45< EliDupree2> Also unit animation filters as you mentioned
20170204 20:00:06< gfgtdf> EliDupree2: ye right
20170204 20:00:19< EliDupree2> brb
20170204 20:00:43< gfgtdf> EliDupree2: well, in 1.13 [set_varaible] was ported to lua, so if this was the issue it shoul be fixed by that
20170204 20:02:19< EliDupree2> heh
20170204 20:05:39< EliDupree2> So I'm guessing the issue is something like iterators into cfg structures being invalidated by unrelated modifications to those structures
20170204 20:08:05< EliDupree2> Meaning I should avoid almost all wesnoth actions during theme items, INCLUDING changing variables... hmm
20170204 20:17:18< gfgtdf> EliDupree2: why do you change those variables in the first place ?
20170204 20:18:11< EliDupree2> I'm not sure if I actually am. But I do a bunch of shenanigans in theme items
20170204 20:26:12< EliDupree2> ahhhh... I use set_variable so I can use $ substitutions in translatable strings. Not that anyone has actually translated EoHS, but
20170204 20:26:47< gfgtdf> EliDupree2: hmm i see.
20170204 20:27:35< gfgtdf> EliDupree2: hmm i dont tihnk there is a bettweer way to do subsitution i translated string currently
20170204 20:27:56< gfgtdf> EliDupree2: maybe you shodul jua make sure the varible uses a differnt container.
20170204 20:28:36< EliDupree2> hmm
20170204 20:30:37< EliDupree2> I'd rather play it extra safe. Just make EoHS a bit harder to translate, given that no one has translated it in like 5 years anyway
20170204 20:36:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170204 20:38:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170204 20:49:43-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 20:55:34-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 21:03:46< EliDupree2> Hmm... I removed wesnoth.set_variable and wesnoth.wml_actions.set_variable during my theme items, but the crash still happens
20170204 21:04:08< EliDupree2> Maybe there's something else inside the theme items that is still breaking things
20170204 21:09:37< EliDupree2> ...Or maybe I forgot to reload my files before testing
20170204 21:13:01< EliDupree2> Yay! Seems 'fixed'
20170204 21:27:26-!- Kwandulin [~Miranda@p200300760F6EBFC3C99E9F91011D1C22.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20170204 21:28:18< EliDupree2> Interesting… I wondered if this fix also applied to the zombie animations segfault that I've encountered in the past, so I tried it out, but I'm getting a stack overflow now – just endlessly repeating
20170204 21:28:24< EliDupree2> #48 0x00000000006913e1 in luaW_toconfig(lua_State*, int, config&, int) ()
20170204 21:29:43< gfgtdf> EliDupree2: that last line ?
20170204 21:29:52< EliDupree2> ?
20170204 21:30:18< gfgtdf> EliDupree2: did you wnt to post a stacktrace or did you acidently post that line
20170204 21:30:43< EliDupree2> I mean, that line is repeated 1000+ times (only differing in the #)
20170204 21:30:51< gfgtdf> hmm ok
20170204 21:31:23< gfgtdf> EliDupree2: maybe you are trying to pass a table that containes  itself to a function that wants a wml table
20170204 21:31:30< EliDupree2> interesting
20170204 21:31:59< gfgtdf> e.g "loal a = { { "a"} }; a[1][2] = a"
20170204 21:32:27< gfgtdf> and then pass a to a wensoth. function
20170204 21:33:54< gfgtdf> EliDupree2: the stacktrace shodul also tell you the name of the (lua) function that is called
20170204 21:34:06< EliDupree2> how?
20170204 21:34:45< gfgtdf> EliDupree2: just leik for the set_variable ? I mean the stacktrace shodul usuualy start (< #20 or something) with someone else then luaW_toconfig
20170204 21:35:05< gfgtdf> ah no sry i meant the last entry not the first
20170204 21:35:27< EliDupree2> Yeah, I had to scroll through about 32,000 of them
20170204 21:36:11< gfgtdf> unless your textedtiro is strange, scrolling to the end is one click/button independen of the size of the file.
20170204 21:36:34< EliDupree2> It's not a file, I'm looking at it in GDB
20170204 21:37:45< gfgtdf> hmm never used gdb, maby it has a n export to file option?
20170204 21:37:45< EliDupree2> http://pastebin.com/7ZYbi6Sq
20170204 21:39:05< gfgtdf> EliDupree2: hmm the function seems to be wesnoth.tovconfig
20170204 21:40:47< gfgtdf> EliDupree2: wesnoth.fire, the metatable returned by helper.set_wml_action_metatable and some wml tad implementations also use wesnoth.tovconfig internally
20170204 21:41:24< EliDupree2> yeah...
20170204 21:41:46< EliDupree2> It doesn't look like it's a case of me calling tovconfig explicitly
20170204 21:43:04< EliDupree2> Luckily, I only have a fairly small chunk of my code that I need to search for bad tables
20170204 21:43:42< gfgtdf> EliDupree2: well you could write a function bool table_contins_iitself_recursiveley and then replac "function wesnoth.tovconifg(cfg) if(contains_itself_recurtsiveley) then throw end return wesnoth_tovconifg_old(cfg) end"
20170204 21:43:51< EliDupree2> neat
20170204 21:44:13< EliDupree2> At least as something to enable for debugging purposes
20170204 21:50:23-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20170204 21:51:15< gfgtdf> EliDupree2: untested code: http://pastebin.com/BYsi6QH4
20170204 21:51:25< gfgtdf> mattsc: did you see my comment earlier ?
20170204 21:51:47< mattsc> gfgtdf: yes, that’s why I am here
20170204 21:52:05< gfgtdf> EliDupree2: the second search_recursiveley(k, search)  shodul obviously be search_recursiveley(v, search) 
20170204 21:52:07< mattsc> I am trying to figure out whether you said why you want to do that
20170204 21:52:21< gfgtdf> mattsc: no i didnt
20170204 21:52:52-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 21:55:54< EliDupree2> gfgtdf: Thanks, you sent that just before I was going to start writing it myself :-) I had to fix it up a bit but it seems to work
20170204 21:56:24< mattsc> gfgtdf: I just did a grep on the data directory, and it looks like this is only used in two places: SotBE-S6 and the Forest Animals Micro AI.
20170204 21:56:40< mattsc> So it would not be a big deal to change this in mainline.
20170204 22:01:20-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 22:04:23< EliDupree2> gfgtdf: Just making sure, can I include that code as part of EoHS (i.e. under the GPL)?
20170204 22:05:21< gfgtdf> sure
20170204 22:07:20< gfgtdf> EliDupree2: you foudn your bug ?
20170204 22:07:41< EliDupree2> Still working on it
20170204 22:09:30-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 22:17:51< EliDupree2> … I've tracked the exact part of the code with the problem happens, and debug printed the bizarre recursive table it's using, I just haven't figured out how that table is being generated yet
20170204 22:24:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170204 22:26:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170204 22:26:17-!- JyrkiVesterinen [~JyrkiVest@87-100-233-147.bb.dnainternet.fi] has quit [Quit: .]
20170204 22:36:29< EliDupree2> OMG, it's because I carelessly didn't fix my indentation and put something inside a loop when it shouldn't have been :/
20170204 22:45:07< gfgtdf> EliDupree2: does your editor have auto indention ?
20170204 22:46:20< EliDupree2> Well, that's all fixed now. Not exactly what was planning to do with my 5 hours, but hey
20170204 22:46:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170204 22:47:19< EliDupree2> gfgtdf: It's weird custom editor to be compatible with Dragon NaturallySpeaking. It has auto indent while you type, but it doesn't have a feature to change the indentation of a lot of lines in a batch
20170204 22:47:25-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 22:47:52< EliDupree2> So when I stuck an if block around a bunch of code, I neglected to go through and indent each line more
20170204 22:47:52-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 22:48:05-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
20170204 22:48:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170204 23:02:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170204 23:03:06-!- Bhoren [~Bhoren_wi@lns-bzn-20-82-64-3-181.adsl.proxad.net] has quit [Read error: Connection reset by peer]
20170204 23:03:33-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170204 23:24:05-!- Duthlet [~Duthlet@dslb-188-105-120-162.188.105.pools.vodafone-ip.de] has quit [Quit: leaving]
20170204 23:24:39-!- UnwiseOwl [~UnwiseOwl@81.168.19.242] has joined #wesnoth-dev
20170204 23:30:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 255 seconds]
20170204 23:31:09-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170204 23:31:58-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20170204 23:37:48-!- stikonas_ is now known as stikonas
20170204 23:46:36-!- UnwiseOwl [~UnwiseOwl@81.168.19.242] has quit [Ping timeout: 240 seconds]
20170204 23:47:52-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has quit [Remote host closed the connection]
20170204 23:52:40-!- Bonobo [~Bonobo@2001:44b8:254:3200:b0f7:1ef:4a7b:b811] has joined #wesnoth-dev
20170204 23:52:59-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:392d:828b:1228:cb31] has joined #wesnoth-dev
--- Log closed Sun Feb 05 00:00:39 2017