--- Log opened Wed Mar 26 00:00:13 2014
20140326 00:01:07< mattsc> Well, since it is super easy to test, I decided to run a bisect on the issue I reported on above.
20140326 00:01:52< mattsc> iceiceice: it’s https://github.com/wesnoth/wesnoth/commit/736ceaa6c7e81882c9c5b2e932307b1f1ecb3bfd
20140326 00:03:30< gfgtdf> AI0867: you said you also have concerns about implementing the Determinisitc mode for SP ?
20140326 00:03:30-!- travis-ci [~travis-ci@ec2-54-221-152-237.compute-1.amazonaws.com] has joined #wesnoth-dev
20140326 00:03:31< travis-ci> [travis-ci] gfgtdf/wesnoth-old#77 (sync_2 - 043c5fa : gfgtdf): The build was broken.
20140326 00:03:31< travis-ci> [travis-ci] Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/21552636
20140326 00:03:31-!- travis-ci [~travis-ci@ec2-54-221-152-237.compute-1.amazonaws.com] has left #wesnoth-dev []
20140326 00:03:58< gfgtdf> unused variable
20140326 00:17:57< gfgtdf> any1 else has concerns about inplementing the deterministic mode for sp ?
20140326 00:28:15-!- Kexoth [~kex@78.157.29.205] has joined #wesnoth-dev
20140326 00:28:29-!- Aishiko_laptop_ [~unknown@198.85.71.18] has joined #wesnoth-dev
20140326 00:31:23-!- Aishiko_laptop [~unknown@198.85.71.253] has quit [Ping timeout: 246 seconds]
20140326 00:40:39-!- travis-ci [~travis-ci@ec2-54-221-152-237.compute-1.amazonaws.com] has joined #wesnoth-dev
20140326 00:40:40< travis-ci> [travis-ci] gfgtdf/wesnoth-old#78 (sync_2 - 32205a2 : gfgtdf): The build was fixed.
20140326 00:40:40< travis-ci> [travis-ci] Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/21554281
20140326 00:40:40-!- travis-ci [~travis-ci@ec2-54-221-152-237.compute-1.amazonaws.com] has left #wesnoth-dev []
20140326 00:40:57< gfgtdf> Soliton: the commit id has changed https://github.com/gfgtdf/wesnoth-old/commit/32205a2e47de8130274f787e549e3a882afebbee
20140326 00:54:26-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140326 00:55:04< iceiceice> mattsc: what exactly is the problem?
20140326 00:55:06-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20140326 00:57:45< iceiceice> i haven't had any problems making all computer games through the usual create dialog
20140326 00:58:42< iceiceice> the commit you pointed out is doing some changes to how controllers work, it changes both client and server code
20140326 00:58:59-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has quit [Quit: leaving]
20140326 00:59:13< iceiceice> i dont know if the official 1.11.12 server has been restarted, but check if you still get a bug using a local instance of wesnothd from master
20140326 01:00:06< iceiceice> theres also further changes to this intended, Soliton has asked that all "controller tweaks" which are currently done client side be moved over to server side
20140326 01:00:16< iceiceice> and also that we purge the "human_ai" controller type as this is confusing
20140326 01:00:30< iceiceice> i didnt make much time this week to work on it though, my pr is still buggy
20140326 01:00:31< iceiceice> https://github.com/wesnoth/wesnoth/pull/123
20140326 01:10:23< mattsc> iceiceice: it has nothing to do with servers etc.
20140326 01:10:49< iceiceice> ok so whats the simplest case to reproduce the bug?
20140326 01:11:04< mattsc> The problem is that I get a “you have been defeated” message as soon as I start one of the AI test scenarios.
20140326 01:11:19< mattsc> iceiceice: CL: wesnoth -t animals
20140326 01:11:30< Aishiko_laptop_> gees mattsc I thought you were a better player then that =P
20140326 01:11:39< mattsc> The select “I’ll watch the animal AI’s do their thing”
20140326 01:11:39< iceiceice> ok but is there a simpler scenario?
20140326 01:11:48< iceiceice> i can start all ai local games just fine
20140326 01:11:52< iceiceice> or on mp server
20140326 01:12:11< mattsc> iceiceice: please read up about a couple hours earlier in the log.  I explain exactly what the problem is there.
20140326 01:12:48< iceiceice> mattsc: i currently can't even get the micro-ai's to load without getting lua errors everywhere. not that that is your fault but it seems like its not the best test case for this
20140326 01:13:45< mattsc> iceiceice: it has absolutely nothing to do with the MAIs - that’s just the simplest way to get a test case  (please read the logs; I’m online but have no time to sit here right now)
20140326 01:14:10< iceiceice> oh i missed some of your comments
20140326 01:14:12< iceiceice> sorry
20140326 01:17:17< iceiceice> mattsc: before you go, can you detail how you used git bisect here? i'm a novice in regards to that, and i might want to be able to repeat what you did
20140326 01:19:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140326 01:19:45< mattsc> iceiceice: I’m not gone, still here.  :)  I’m just busy with “chores”, so only can stop by occassionally.
20140326 01:20:12< mattsc> iceiceice: I usually follow this for git bisect:  http://webchick.net/node/99
20140326 01:21:12< mattsc> There are probabably better guides out there, but this is one that made sense to me when I found it doing a random Net search some day, so I bookmarked it.
20140326 01:21:30< iceiceice> yeah so did you write a script to call "wesnoth -t animals" or something? does wesnoth give return type -1/0 or something if it errors?
20140326 01:21:45< iceiceice> or did you do it manually
20140326 01:22:28< mattsc> iceiceice: no, I just ran it by hand - since I knew 2 commits pretty close to each other that were a good/bad pair, it was only 6 iterations or so.
20140326 01:22:36< iceiceice> ok thanks
20140326 01:22:56< mattsc> I laos was in no hurry, so just let the computer do its thing and got back to it in between other things.  :)
20140326 01:23:04< shadowm> 21:59:11 <iceiceice> i dont know if the official 1.11.12 server has been restarted
20140326 01:23:12< shadowm> iceiceice: Do you read the logs?
20140326 01:24:46< iceiceice> i remember that there was something about it but i didnt remember if it was before or after these commits, sry
20140326 01:25:16< shadowm> It was from today if that helps.
20140326 01:25:43-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Ping timeout: 264 seconds]
20140326 01:26:43-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140326 01:26:53< gfgtdf> shadowm: i pulling form the original master into my feature fork a nomraly way so solve merging conflicts ?
20140326 01:26:55-!- Spoffy [~chatzilla@152.78.175.8] has quit [Read error: Operation timed out]
20140326 01:26:57< gfgtdf> s/i/is
20140326 01:28:24< shadowm> Not sure. Most people here seem to prefer rebase for preparing patches like that downstream.
20140326 01:29:29-!- spoffy_ [~spoffy@152.78.175.8] has quit [Ping timeout: 246 seconds]
20140326 01:30:18< gfgtdf> what is 'downstream' ?
20140326 01:31:22< shadowm> The opposite of upstream.
20140326 01:32:18-!- Coffee_irc [~david@ppp118-210-31-67.lns20.adl2.internode.on.net] has quit [Ping timeout: 240 seconds]
20140326 01:32:48< shadowm> It's particularly important to keep in mind that destructive/history rewrite operations like git reset, rebase, commit --amend and so on are only acceptable practice when done on downstream commits not yet pushed upstream, except under extremely rare circumstances which for most intents and purposes you can pretend don't even happen.
20140326 01:32:59< shadowm> Forgot to include push -f in that list.
20140326 01:33:48< shadowm> Rebasing and force-pushing a branch for a pull request that hasn't been merged upstream yet? Acceptable.
20140326 01:34:09< shadowm> Rebasing and force-pushing a branch that has already been merged upstream/is a public upstream branch? Absolutely unacceptable.
20140326 01:34:19< gfgtdf> but i didn't plan do to rebasing.
20140326 01:34:25< gfgtdf> to do*
20140326 01:34:47< gfgtdf> or do i autimaticly rebase when pulling from master ?
20140326 01:34:58< shadowm> Not unless you change your configuration to do so.
20140326 01:35:41< shadowm> By default git pull does a repository fetch for all heads followed by a merge, not a rebase.
20140326 01:36:04< gfgtdf> and this is not good ?
20140326 01:36:13< shadowm> It depends on what you want to do.
20140326 01:36:27< gfgtdf> i want to merge my pr into master but it has merging conflicts
20140326 01:36:50< shadowm> You want to merge your PR into master, merge master into your PR, or rebase your PR on top of master?
20140326 01:37:19< shadowm> All three are things someone might want to do and they all involve completely different procedures and consequences.
20140326 01:38:27< gfgtdf> i want to merge my pr into master, but i don't have a local copy of master, and i want to use the 'Mergee' button on the github webpage to do so, and to to that i have to eliminate the mergin conflicts first and in order to do so my idea was to pull master into my pr.
20140326 01:39:21< gfgtdf> shadowm: ^
20140326 01:39:44< shadowm> In order to have made that PR you must have a clone of the Wesnoth repository. Do you still have that clone?
20140326 01:40:13< gfgtdf> shadowm: i have a clone of github.com/gfgtdf/wesnoth-old
20140326 01:40:17-!- Aishiko_laptop_ [~unknown@198.85.71.18] has quit [Ping timeout: 240 seconds]
20140326 01:40:45< gfgtdf> of my fork
20140326 01:41:12< shadowm> Let me put it like this: regardless of the choice you make, you need a clone of the Wesnoth repository. However, you don't need to clone the whole thing if your fork is a fork of the Wesnoth repository.
20140326 01:42:42< shadowm> It already shares all of Wesnoth's history up to the point at which you first made the fork. The easiest solution in this case would be to just add the wesnoth/wesnoth URL as a new 'upstream' remote, fetch, and do a bunch of  command-line magic to prepare your branch for merging into upstream/master (as opposed to origin/master).
20140326 01:44:15< shadowm> But I am really tired and I believe that I'm not the best person to walk you through the procedure. This is totally unrelated to my lack of experience juggling multiple remotes for a single downstream repository.
20140326 01:44:16< gfgtdf> shadowm: see the last commit here: https://github.com/wesnoth/wesnoth/pull/121/commits is that ok like this ?
20140326 01:44:46< iceiceice> gfgtdf: you can rebase to resolve merge conflicts
20140326 01:45:21< shadowm> iceiceice: Yes, but to rebase you need the new refs, hence "regardless of the choice you make" above.
20140326 01:45:24< iceiceice> i assume you have a topic branch, which branches off of master, and you want to make it consistent with master for a pull request?
20140326 01:45:33< iceiceice> yeah you need to update master
20140326 01:45:34< iceiceice> locally
20140326 01:45:52< iceiceice> and then if you rebase it will show you the merge conflicts and you can resolve
20140326 01:45:59< gfgtdf> iceiceice: yes and in order to do so i mathe teh last commit in this list:  https://github.com/wesnoth/wesnoth/pull/121/commits
20140326 01:46:18< gfgtdf> iceiceice: not i se the green button "Able to merge" so i assume i did it right
20140326 01:46:22< gfgtdf> s/not/now
20140326 01:46:43< shadowm> I don't like that merge commit, let's see what happens if I attempt to merge the end result.
20140326 01:46:45< iceiceice> gfgtdf: i would not merge master into your pr
20140326 01:47:10< iceiceice> i mean if it works more power to you but i think its not recommended
20140326 01:47:57-!- Coffee_irc [~david@ppp118-210-37-247.lns20.adl2.internode.on.net] has joined #wesnoth-dev
20140326 01:48:01< iceiceice> if it were me i would just rebase onto master instead
20140326 01:48:02< shadowm> After I finish catching up on all the breakage I missed these last few days.
20140326 01:49:48< gfgtdf> iceiceice, shadowm:  i did it wrong
20140326 01:50:03< gfgtdf> iceiceice, shadowm: there are 2 merge conflics in that file but i only solved one
20140326 01:52:59< _8680_> AI0867: So, yes, I failed to either make those functions compatible with non–two’s-complement representations or document that they weren’t; mea culpa.
20140326 01:53:30< _8680_> (And after my bother to make them compatible with non-octet bytes, too.)
20140326 01:56:39< _8680_> I could return 0 if `N` is signed and `n < 0`, but I believe I’d need C++11 to check whether `N` is signed.
20140326 01:56:48< gfgtdf> iceiceice, shadowm: now with all merge fixes
20140326 01:56:57-!- neXyon [~neXyon@85-127-36-114.dynamic.xdsl-line.inode.at] has quit [Quit: bye]
20140326 01:57:22< _8680_> I could just document the issue once the changes land (if they haven’t already).
20140326 01:58:13< _8680_> Or someone better than I with bit-fiddling could make the functions compatible.
20140326 01:59:34< gfgtdf> iceiceice: you mean rebasing from my pr into wesnoth/master ?
20140326 01:59:39< iceiceice> yes
20140326 01:59:46< iceiceice> git checkout topic && git rebase master
20140326 02:00:17< gfgtdf> iceiceice: but i cannot use the green button the git github webpage then right ?
20140326 02:00:21< iceiceice> yes you can
20140326 02:00:36< iceiceice> what will happen is, it will update the PR so that it branches from current master instead of the old departure point,
20140326 02:00:47< iceiceice> and add your commits one by one
20140326 02:00:55< iceiceice> each time theres a merge conflict, it will stop and say "fix this"
20140326 02:01:28< iceiceice> at the end you won't have a merge commit
20140326 02:01:32< iceiceice> except when your pr actually gets pulled
20140326 02:01:46< gfgtdf> so when rebasing  from sync_2 onto  master teh 'result' gets onti sync_2 not into master ?
20140326 02:01:53< iceiceice> yes
20140326 02:02:29< iceiceice> rebase is pretty awesome this way 
20140326 02:02:30< iceiceice> :)
20140326 02:03:08-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has joined #wesnoth-dev
20140326 02:08:50< gfgtdf> iceiceice: so i pull original master to my master first and then rebase onto master ?
20140326 02:09:29< iceiceice> yeah
20140326 02:12:15< gfgtdf> iceiceice: do i use rebase with -i or without i for that ?
20140326 02:12:25< iceiceice> you can use it without -i
20140326 02:13:47< gfgtdf> ok i'll try that
20140326 02:26:10-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 246 seconds]
20140326 02:27:29-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20140326 02:27:40< gfgtdf> iceiceice: ok i did that
20140326 02:28:39< iceiceice> does it look like you can merge pr now?
20140326 02:28:51< gfgtdf> iceiceice: yes
20140326 02:29:22< iceiceice> cool :)
20140326 02:31:48< gfgtdf> iceiceice: ye
20140326 02:37:21< iceiceice> mattsc: i have played around with the test case you described and checked controller types...
20140326 02:38:09< iceiceice> i dont see any obvious problems that the commit could have introduced, only this stuff in src/playturn.cpp would even be active i think
20140326 02:38:25< iceiceice> the other stuff should be unreachable
20140326 02:48:03-!- Incredible_ [~Incredibl@14.139.122.114] has joined #wesnoth-dev
20140326 02:48:30-!- Incredible_ [~Incredibl@14.139.122.114] has quit [Client Quit]
20140326 02:55:07< iceiceice> matt_sc: i'm somewhat doubtful now that that is actually the right commit, but i think i know what the problem is anyways
20140326 03:05:39-!- Ivanovic_ [~ivanovic@x2f469c0.dyn.telefonica.de] has joined #wesnoth-dev
20140326 03:07:03-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Read error: Operation timed out]
20140326 03:07:33-!- Ivanovic_ is now known as Ivanovic
20140326 03:07:40< iceiceice> mattsc: ok i dont know what the problem is, but i've found that when i checkout both the commit you referenced, and the subsequent commit, wesnoth -t animals works just fine
20140326 03:08:32< iceiceice> can you please confirm this: 20140326 00:01:52< mattsc> iceiceice: it’s https://github.com/wesnoth/wesnoth/commit/736ceaa6c7e81882c9c5b2e932307b1f1ecb3bfd
20140326 03:08:43-!- Ivanovic [~ivanovic@x2f469c0.dyn.telefonica.de] has quit [Changing host]
20140326 03:08:43-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20140326 03:11:15-!- Kexoth [~kex@78.157.29.205] has quit [Remote host closed the connection]
20140326 03:11:49-!- Kexoth [~kex@78.157.29.205] has joined #wesnoth-dev
20140326 03:16:24-!- Kexoth [~kex@78.157.29.205] has quit [Ping timeout: 268 seconds]
20140326 03:17:46-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20140326 03:23:53< iceiceice> mattsc: i even find that animals works at this commit: 8e9fcd1704c1def04cabdda710a62a02d069f07f
20140326 03:26:55< iceiceice> <mattsc> iceiceice: no, I just ran it by hand - since I knew 2 commits pretty close to each other that were a good/bad pair, it was only 6 iterations or so.
20140326 03:27:24< iceiceice> what commits were these?
20140326 03:27:27-!- gfgtdf [~chatzilla@f054146168.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140314220517]]
20140326 03:33:14-!- vorobeez [558e940c@gateway/web/freenode/ip.85.142.148.12] has joined #wesnoth-dev
20140326 03:33:42< iceiceice> anyways: mattsc i think the issue might be this... the victory when defeated flag is checked here: 
20140326 03:33:43< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/play_controller.cpp#L1419
20140326 03:34:03< iceiceice> is_observer is defined here: https://github.com/wesnoth/wesnoth/blob/master/src/team.cpp#L649
20140326 03:35:14< iceiceice> i'm not sure if is_observer is taking into account empty sides correctly?
20140326 03:35:27< iceiceice> someone would have to confirm i guess
20140326 03:35:39< iceiceice> might be worthwhile to try to put some debugging output at play_controller.cpp at first link
20140326 03:36:02< iceiceice> idk i'm not working on this right now, i dont think i caused this
20140326 03:49:28-!- vorobeez [558e940c@gateway/web/freenode/ip.85.142.148.12] has quit [Quit: Page closed]
20140326 03:58:17< iceiceice> mattsc: to be completely clear: these are the SHAs of the two commits i checked out, in additon to 8e9fcd, all of which worked:
20140326 03:58:21< iceiceice> Previous HEAD position was 736ceaa... fix bug #18829
20140326 03:58:21< iceiceice> HEAD is now at b854aab... don't display network_ai sides as replacements for dropped sides
20140326 03:58:52< iceiceice> and master does not work for me
20140326 04:02:32< mattsc> iceiceice: thanks for all the messages and sorry, I just don’t have time for this tonight any more.
20140326 04:02:34-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20140326 04:02:45< mattsc> I’ll look into it tomorrow.  I appreciate all the work you’ve done on this though, thanks.
20140326 04:02:48< iceiceice> y me either, hopefully we figure it out
20140326 04:02:56< iceiceice> soon that is
20140326 04:03:14< mattsc> I’m sure we will.  TTYL.
20140326 04:05:37-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has joined #wesnoth-dev
20140326 04:08:00-!- RiftWalker [~RiftWalke@c-76-22-135-46.hsd1.tn.comcast.net] has joined #wesnoth-dev
20140326 04:20:48-!- Kexoth [~kex@78.157.29.205] has joined #wesnoth-dev
20140326 04:21:08-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Quit: Leaving]
20140326 04:21:22-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140326 04:23:17-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20140326 04:26:05-!- Kexoth [~kex@78.157.29.205] has quit [Ping timeout: 268 seconds]
20140326 04:28:05-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has joined #wesnoth-dev
20140326 04:40:11-!- irker474 [~irker@ai0867.net] has joined #wesnoth-dev
20140326 04:40:11< irker474> wesnoth: Chris Beck wesnoth:master 56bdb6aa055d / src/ (6 files): blindfold is removed when control of a side is received http://git.io/yKnBuw
20140326 04:43:14-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Remote host closed the connection]
20140326 04:44:32-!- shadowm_desktop [ignacio@186.11.11.66] has joined #wesnoth-dev
20140326 04:44:35-!- shadowm_desktop [ignacio@186.11.11.66] has quit [Signing in (shadowm_desktop)]
20140326 04:44:35-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140326 04:44:51-!- shadowm_desktop is now known as Guest4315
20140326 04:53:13< irker474> wesnoth: Chris Beck wesnoth:1.12 3c970047cfc5 / src/ (6 files): blindfold is removed when control of a side is received http://git.io/QHxViw
20140326 05:06:37< iceiceice> question: how do i delete a dead branch on wesnoth?
20140326 05:06:42< iceiceice> is the best way to just use the github interface?
20140326 05:06:57-!- RiftWalker [~RiftWalke@c-76-22-135-46.hsd1.tn.comcast.net] has quit [Ping timeout: 240 seconds]
20140326 05:07:22< iceiceice> i want to delete this one
20140326 05:07:22< iceiceice> https://github.com/wesnoth/wesnoth/tree/blindfold_turn_dialog
20140326 05:07:31-!- Guest4315 [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 246 seconds]
20140326 05:10:40-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20140326 05:14:42< irker474> wesnoth: Chris Beck wesnoth:master 15a4c1f74c5f / changelog players_changelog src/playsingle_controller.cpp: apply a brief blindfold when changing sides in hotseat mp http://git.io/xWuP-w
20140326 05:16:33< iceiceice> nm i just removed it from the github interface
20140326 05:20:45-!- sachith500 [~kvirc@112.134.231.72] has joined #wesnoth-dev
20140326 05:21:08-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140326 05:22:38< iceiceice> hmm...
20140326 05:23:11< iceiceice> i am finding that i can sometimes crash wesnoth by opening preferences with ctrl+p ...
20140326 05:23:18< iceiceice> not sure exactly what the conditions are
20140326 05:23:30< iceiceice> but it crashes right to command prompt, with this on std::out http://pastebin.com/S6kSP16r
20140326 05:24:07< iceiceice> does anyone know anything about this?
20140326 05:25:12-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20140326 05:27:20< noy> wesbot: seen boucman?
20140326 05:27:20< wesbot> noy: The person with the nick boucman last spoke 15d 21h ago.  5d 5h ago they left with the message: Remote host closed the connection
20140326 05:30:53-!- RiftWalker [~RiftWalke@c-76-22-135-46.hsd1.tn.comcast.net] has joined #wesnoth-dev
20140326 05:36:57-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20140326 06:08:59-!- Kexoth [~kex@78.157.29.205] has joined #wesnoth-dev
20140326 06:11:38-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has joined #wesnoth-dev
20140326 06:13:38-!- Kexoth [~kex@78.157.29.205] has quit [Ping timeout: 252 seconds]
20140326 06:15:12-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Ciao]
20140326 06:54:34-!- zookeeper [~lmsnie@37.35.27.57] has joined #wesnoth-dev
20140326 06:54:40-!- zookeeper [~lmsnie@37.35.27.57] has quit [Changing host]
20140326 06:54:40-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20140326 07:04:04-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140326 07:11:55-!- Kexoth [~kex@78.157.29.205] has joined #wesnoth-dev
20140326 07:16:23-!- Kexoth [~kex@78.157.29.205] has quit [Ping timeout: 252 seconds]
20140326 07:17:06-!- sachith500 [~kvirc@112.134.231.72] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140326 07:17:50< RiftWalker> ls
20140326 07:17:56< RiftWalker> ls
20140326 07:17:57< RiftWalker> ls
20140326 07:17:57< RiftWalker> ls
20140326 07:17:58< RiftWalker> ls
20140326 07:17:58< RiftWalker> l
20140326 07:18:01< RiftWalker> ls
20140326 07:18:33< zookeeper> really
20140326 07:19:01< vultraz> he seems to do that a lot
20140326 07:19:26< RiftWalker> o
20140326 07:20:55< RiftWalker> What would be the best way to print out the whole contents of a config for debug purposes?
20140326 07:25:18< iceiceice> i think theres a debug function?
20140326 07:25:28< iceiceice> hold on i'll give you a code reference
20140326 07:26:39< iceiceice> https://github.com/cbeck88/wesnoth-old/blob/41185bad6ea727cef5d14c20ca5ebd5811f4e010/src/server/game.cpp#L160
20140326 07:26:52< iceiceice> oh wait thats not a good one
20140326 07:27:49< iceiceice> i think you want to use this maybe: https://github.com/wesnoth/wesnoth/blob/master/src/config.cpp#L1328
20140326 07:28:37< iceiceice> yeah if you grep ".debug()" you'll find lots of example debugging output using this for configs
20140326 07:31:26< RiftWalker> Thanks. That's exactly what i'm looking for.
20140326 07:36:08< iceiceice> brb
20140326 07:36:09-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Quit: Leaving]
20140326 07:38:49-!- Kevin_Xi [~kevin@223.72.182.191] has joined #wesnoth-dev
20140326 07:44:54-!- trademark [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has joined #wesnoth-dev
20140326 07:59:49-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140326 08:02:41-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20140326 08:03:48-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20140326 08:14:45-!- irker474 [~irker@ai0867.net] has quit [Quit: transmission timeout]
20140326 08:21:45-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has joined #wesnoth-dev
20140326 08:25:20-!- neXyon [~neXyon@85-127-35-27.dynamic.xdsl-line.inode.at] has joined #wesnoth-dev
20140326 08:25:22< RiftWalker> Well, I got sp campaigns to at least show up in the mp dialog and load as such. Able to select add-ons etc but I'm not sure how broken it is.
20140326 08:34:18-!- neXyon_ [~neXyon@85-127-75-96.dynamic.xdsl-line.inode.at] has joined #wesnoth-dev
20140326 08:37:16-!- neXyon [~neXyon@85-127-35-27.dynamic.xdsl-line.inode.at] has quit [Ping timeout: 265 seconds]
20140326 08:39:19-!- ancestral [~ancestral@75-161-229-57.mpls.qwest.net] has quit [Quit: End Transmission.]
20140326 08:46:32-!- RiftWalker [~RiftWalke@c-76-22-135-46.hsd1.tn.comcast.net] has quit [Ping timeout: 252 seconds]
20140326 08:48:16-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20140326 08:49:24-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Quit: leaving]
20140326 08:54:22-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140326 08:55:16-!- Kexoth [~kex@89.205.75.19] has quit [Read error: Connection reset by peer]
20140326 08:55:32-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140326 08:57:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140326 09:00:31-!- Kexoth [~kex@89.205.75.19] has quit [Ping timeout: 264 seconds]
20140326 09:04:46-!- Spoffy [~chatzilla@152.78.175.8] has joined #wesnoth-dev
20140326 09:04:59-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140326 09:11:33-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140326 09:16:05-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20140326 09:19:06-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20140326 09:19:27-!- mjs-de [~mjs-de@f049173156.adsl.alicedsl.de] has joined #wesnoth-dev
20140326 09:26:43-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginmedia.com] has joined #wesnoth-dev
20140326 09:33:07-!- Spoffy [~chatzilla@152.78.175.8] has quit [Read error: Operation timed out]
20140326 09:50:53-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginmedia.com] has quit [Remote host closed the connection]
20140326 09:58:49-!- demiurgos [96d6cd3e@gateway/web/freenode/ip.150.214.205.62] has joined #wesnoth-dev
20140326 10:04:07-!- trademark [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has quit [Ping timeout: 264 seconds]
20140326 10:09:15-!- Rhonda [~rhonda@anguilla.debian.or.at] has quit [Changing host]
20140326 10:09:15-!- Rhonda [~rhonda@wesnoth/developer/rhonda] has joined #wesnoth-dev
20140326 10:15:06< demiurgos> hi, i think that one interesting change for random map generating is that island landform maps have a bit more water, while coastal maps, that are now 50/50, have more land
20140326 10:17:49-!- Octalot [~noct@31.185.149.167] has joined #wesnoth-dev
20140326 10:23:47-!- spoffy_ [~spoffy@2001:630:d0:ed05:39ea:be97:8630:ccf9] has joined #wesnoth-dev
20140326 10:28:57-!- demiurgos [96d6cd3e@gateway/web/freenode/ip.150.214.205.62] has quit [Quit: Page closed]
20140326 10:32:55-!- Kevin_Xi [~kevin@223.72.182.191] has quit [Ping timeout: 264 seconds]
20140326 10:53:27-!- trademark [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has joined #wesnoth-dev
20140326 10:54:49-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20140326 10:55:43-!- spoffy_ [~spoffy@2001:630:d0:ed05:39ea:be97:8630:ccf9] has quit [Ping timeout: 264 seconds]
20140326 11:14:50-!- timotei__ [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 265 seconds]
20140326 11:15:25-!- timotei_ [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20140326 11:25:20-!- juanmi91 [5126e6e4@gateway/web/freenode/ip.81.38.230.228] has joined #wesnoth-dev
20140326 11:25:34< juanmi91> hi?
20140326 11:26:32< juanmi91> i'm a student in GSoC with you
20140326 11:27:34< juanmi91> anybody here?
20140326 11:30:17< zookeeper> sure
20140326 11:32:06< juanmi91> thanks >.<
20140326 11:32:31< juanmi91> i'm in your forum, my username is juanmi91 like irc user
20140326 11:33:18< zookeeper> there's not many people around here at this time of day
20140326 11:34:41-!- spoffy_ [~spoffy@2001:630:d0:ed05:caf7:33ff:fe0a:4542] has joined #wesnoth-dev
20140326 11:35:05-!- EdB [~edb@85.69.242.6] has joined #wesnoth-dev
20140326 11:35:09< juanmi91> aww, ok
20140326 11:37:30< Soliton> if you have nay questions you can ask them anyway and people will respond when they have time.
20140326 11:37:36< Soliton> s/nay/any/
20140326 11:37:42< juanmi91> it's my first time in GSoC, and i get lost @_@
20140326 11:37:48< juanmi91> aw, thanks >.<
20140326 11:38:20< Rhonda> Soliton: Sure you didn't mean s/nay/noy/?  ;)
20140326 11:51:27-!- neXyon_ [~neXyon@85-127-75-96.dynamic.xdsl-line.inode.at] has quit [Quit: bye]
20140326 11:57:57-!- Incredible [~Incredibl@14.139.122.114] has joined #wesnoth-dev
20140326 11:58:37-!- lipkab [~lipk@2001:738:5404:192:9e4e:36ff:fe7c:534c] has joined #wesnoth-dev
20140326 12:00:13-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has joined #wesnoth-dev
20140326 12:09:21-!- spoffy_ [~spoffy@2001:630:d0:ed05:caf7:33ff:fe0a:4542] has quit [Ping timeout: 245 seconds]
20140326 12:17:23-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has joined #wesnoth-dev
20140326 12:29:24-!- happygrue [~happygrue@c-66-30-155-184.hsd1.ma.comcast.net] has joined #wesnoth-dev
20140326 12:29:24-!- happygrue [~happygrue@c-66-30-155-184.hsd1.ma.comcast.net] has quit [Changing host]
20140326 12:29:24-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140326 12:31:18-!- ykanarev [~ykanarev@212.55.118.222] has joined #wesnoth-dev
20140326 12:40:34-!- knotwork [~markm@unaffiliated/knotwork] has quit [Read error: Connection reset by peer]
20140326 12:40:47-!- Kexoth [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140326 12:41:20-!- knotwork [~markm@unaffiliated/knotwork] has joined #wesnoth-dev
20140326 12:41:31-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140326 12:45:37-!- Kexoth [~kex@89.205.75.19] has quit [Ping timeout: 240 seconds]
20140326 12:53:31-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Quit: Leaving]
20140326 13:02:01-!- juanmi91 [5126e6e4@gateway/web/freenode/ip.81.38.230.228] has quit [Quit: Page closed]
20140326 13:23:07-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140326 13:25:31-!- sachith500 [~kvirc@112.135.156.253] has joined #wesnoth-dev
20140326 13:27:11-!- wesbot changed the topic of #wesnoth-dev to: string+feature freeze active on 1.12 | 230 bugs, 352 feature requests, 28 patches | Logs: http://irclogs.wesnoth.org | Alternate logs: http://wesnoth.debian.net | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20140326 13:30:04-!- spoffy_ [~spoffy@2001:630:d0:ed04:caf7:33ff:fe0a:4542] has joined #wesnoth-dev
20140326 13:37:56< AI0867> shadowm: well, while it looks big, unless you use windows, it's just a rename
20140326 13:40:49< AI0867> so if it compiles, it probably works
20140326 13:47:06-!- mjs-de [~mjs-de@f049173156.adsl.alicedsl.de] has quit [Ping timeout: 265 seconds]
20140326 13:47:30-!- Aishiko_laptop_ [~unknown@198.85.71.253] has joined #wesnoth-dev
20140326 13:51:45-!- Incredible_ [~Incredibl@14.139.122.114] has joined #wesnoth-dev
20140326 13:51:46-!- Incredible [~Incredibl@14.139.122.114] has quit [Read error: Connection reset by peer]
20140326 13:56:49-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140326 14:01:07-!- Kexoth [~kex@89.205.75.19] has quit [Ping timeout: 252 seconds]
20140326 14:06:11-!- daelious [~daelious@74.202.60.2] has joined #wesnoth-dev
20140326 14:08:17-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Computer's napping]
20140326 14:11:15-!- sachith500 [~kvirc@112.135.156.253] has quit [Read error: Connection reset by peer]
20140326 14:14:32-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140326 14:16:39-!- Incredible_ is now known as incredible
20140326 14:18:17-!- incredible [~Incredibl@14.139.122.114] has quit [Quit: Leaving]
20140326 14:18:41-!- neXyon [~neXyon@85-127-75-96.dynamic.xdsl-line.inode.at] has joined #wesnoth-dev
20140326 14:24:26-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140326 14:26:01-!- lipkab [~lipk@2001:738:5404:192:9e4e:36ff:fe7c:534c] has quit [Ping timeout: 245 seconds]
20140326 14:27:51-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140326 14:31:04-!- TooLmaN [~TooLmaN@mx1.thomsonplastics.com] has joined #wesnoth-dev
20140326 14:31:07-!- spoffy_ [~spoffy@2001:630:d0:ed04:caf7:33ff:fe0a:4542] has quit [Quit: Leaving]
20140326 14:49:59-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Quit: leaving]
20140326 14:54:40-!- mjs-de [~mjs-de@f048112109.adsl.alicedsl.de] has joined #wesnoth-dev
20140326 14:58:57-!- daelious [~daelious@74.202.60.2] has quit [Remote host closed the connection]
20140326 14:59:17-!- mjs-de [~mjs-de@f048112109.adsl.alicedsl.de] has quit [Read error: Operation timed out]
20140326 15:00:25< mattsc> iceiceice: sorry for not replying yesterday, I just never got back to the computer last night.
20140326 15:01:01< mattsc> I have now redone the bisecting and found a different commit (but still one of yours): 60777429c3a1d400859831d2f3fa9f910803a1fe
20140326 15:02:01< mattsc> [and this time I double checked and compiled and have confirmed that e149b3f works and 6077742 does not]
20140326 15:02:47-!- mjs-de [~mjs-de@f048022243.adsl.alicedsl.de] has joined #wesnoth-dev
20140326 15:04:09< mattsc> iceiceice: my best guess is that yesterday I copied the commit # in the commit message, rather than that of the commit itself.  I apologize for wasting your time with that, apparently I need some sleep - but at least you now know what you are looking for.  :P
20140326 15:08:06-!- mjs-de [~mjs-de@f048022243.adsl.alicedsl.de] has quit [Ping timeout: 245 seconds]
20140326 15:16:14-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has joined #wesnoth-dev
20140326 15:18:01-!- juanmi91 [5126e6e4@gateway/web/freenode/ip.81.38.230.228] has joined #wesnoth-dev
20140326 15:18:11-!- Aishiko_laptop_ [~unknown@198.85.71.253] has quit [Ping timeout: 252 seconds]
20140326 15:19:18< juanmi91> i submitted my project proposal to your wiki, can you saw if there are any mistakes please? thank you
20140326 15:19:54< juanmi91> and, i can't change the title of my wiki propsal, i think, only the administrators can do this
20140326 15:20:57-!- mjs-de [~mjs-de@f048170213.adsl.alicedsl.de] has joined #wesnoth-dev
20140326 15:22:41-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140326 15:27:08-!- gfgtdf [~chatzilla@f054146168.adsl.alicedsl.de] has joined #wesnoth-dev
20140326 15:27:08< gfgtdf> iceiceice: i updated teh message in my pr.
20140326 15:28:06-!- juanmi91 [5126e6e4@gateway/web/freenode/ip.81.38.230.228] has quit [Quit: Page closed]
20140326 15:28:38-!- juanmi91 [5126e6e4@gateway/web/freenode/ip.81.38.230.228] has joined #wesnoth-dev
20140326 15:30:03-!- juanmi91 [5126e6e4@gateway/web/freenode/ip.81.38.230.228] has quit [Client Quit]
20140326 15:31:01< mattsc> iceiceice: hi - I left you a couple messages about half an hour ago.  Sorry for that mix-up yesterday.
20140326 15:31:09< iceiceice> np
20140326 15:31:26< iceiceice> so i looked at this animal scenario to try to see what is going on
20140326 15:31:44< iceiceice> i guess it has this block:                     [modify_side]
20140326 15:31:44< iceiceice>                         side=1
20140326 15:31:44< iceiceice>                         controller=null
20140326 15:31:44< iceiceice>                         hidden=yes
20140326 15:31:44< iceiceice>                     [/modify_side]
20140326 15:31:55< iceiceice> which is triggered when we select to watch the animals
20140326 15:32:20< mattsc> iceiceice: yes, but I have that in other scenarios as well (or something that has the same effect) and they don’t trigger the defeat message there.
20140326 15:32:26< iceiceice> really?
20140326 15:32:31< iceiceice> i see
20140326 15:32:40< mattsc> iceiceice: I did a lot of tests with that scenario yesterday and I can tell you what triggers the problem.
20140326 15:33:09< mattsc> And as I said, it has nothing to do with the MAIS (I completely eliminated them as one of the tests and it doesn’t change things)
20140326 15:33:46< mattsc> Here’s what’s going on: if you do not have a human controlled side in the scenario, then you need (at least):
20140326 15:34:13< mattsc> 2 AI sides which are enemies of each other, and each of which must have a leader, otherwise the message is triggered.
20140326 15:34:35< mattsc> If they are not enemies of each other, or if one of the sides does not have a leader, you get the defeat message.
20140326 15:35:02< mattsc> So that’s what’s going on in the animals scenario: I have lots of AI sides in it, but none of them has a leader.
20140326 15:36:09< mattsc> By contrast, if you check out the goto test scenario (-t goto) and eliminate the human controlled side, it works because the AI sides in there have leaders (or at least some of them do).
20140326 15:36:45< mattsc> And, yes, the method by which the human controlled side is removed is different between the two scenarios, but I have interchanged those two methods and, again, it does not change anything.
20140326 15:37:47-!- arveanor [827f4897@gateway/web/freenode/ip.130.127.72.151] has joined #wesnoth-dev
20140326 15:39:22< iceiceice> ok so heres the line which implements the victory_when_defeated condition:
20140326 15:39:23< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/play_controller.cpp#L1419
20140326 15:40:11< iceiceice> the "found_player" check is just above it, i didn't change that
20140326 15:40:33< iceiceice> the only way that my PR could have changed things I think is if "is_observer" is becoming false when it should be true
20140326 15:42:23< iceiceice> i did make changes to that function... if i made a logic error it might be very helpful if we sort of piece through it here
20140326 15:43:11< iceiceice> is_observer is defined here: https://github.com/wesnoth/wesnoth/blob/60777429c3a1d400859831d2f3fa9f910803a1fe/src/team.cpp#L649
20140326 15:43:26< iceiceice> if any team is "local" we return false, otherwise we return true
20140326 15:43:37< iceiceice> prior to the commit you referenced, local was "is_human || is_human_ai"
20140326 15:44:04< iceiceice> in your scenario things were "ai" not "human_ai" so this would be affected by purging the human_ai controller type
20140326 15:44:09< iceiceice> afaik
20140326 15:44:32< iceiceice> i defined is_local here: https://github.com/wesnoth/wesnoth/blob/60777429c3a1d400859831d2f3fa9f910803a1fe/src/team.hpp#L216
20140326 15:44:48< iceiceice> { return is_human() || is_ai() || is_idle(); }
20140326 15:45:30< iceiceice> do you see any obvious logic problems here?
20140326 15:45:37< iceiceice> should an "empty" side be considered local?
20140326 15:46:02< gfgtdf> 	iceiceice: NO
20140326 15:46:17< gfgtdf> iceiceice: a side should only be local on one side
20140326 15:46:22< iceiceice> ok
20140326 15:46:25< gfgtdf> iceiceice: not on all sides
20140326 15:46:28< iceiceice> thats what i would have thought
20140326 15:46:37-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140326 15:46:52< gfgtdf> iceiceice: well since empty is a specialy case in anycase iw ould probably not matter
20140326 15:47:10< mattsc> iceiceice: I don’t see an obvious problem, but I also haven’t quite followed it through all the side either.
20140326 15:47:20-!- EdB [~edb@85.69.242.6] has quit [Quit: Konversation terminated!]
20140326 15:47:21< gfgtdf> iceiceice: since you normaly have a ifside.empty() brfore side.is_local/(
20140326 15:47:27< gfgtdf> if*
20140326 15:47:32< mattsc> iceiceice: let me run one quick test
20140326 15:49:28< gfgtdf> s/iw/so
20140326 15:50:01< gfgtdf> s/so ould/so it would
20140326 15:50:24< mattsc> iceiceice: yes, I thought so.  The idle (empty) side 1 is not what causes the problem.  I just turned that side into another AI side without a leader and the defeat still triggers.
20140326 15:50:26< happygrue> juanmi91: if you see this in the logs, look at where your proposal is on the wiki, it's not in the SDL2 section and the template page is still called "new page".  Be sure to following the naming procedure in the template:  http://wiki.wesnoth.org/SoC2014_Template_of_Student_page 
20140326 15:51:55< mattsc> iceiceice: I’ll stay online but have to do some reasonably urgent work right now.  I can dig into this some more later, but probably not until afternoon or evening my time.
20140326 15:52:04< iceiceice> ok
20140326 15:53:12< iceiceice> ok well i can tell you from debugging that the problem is "is_observer" is returning flase
20140326 15:53:14< iceiceice> *false
20140326 15:53:19-!- arveanor [827f4897@gateway/web/freenode/ip.130.127.72.151] has quit [Quit: Page closed]
20140326 15:54:09< mattsc> iceiceice: so to summarize, if you set up a scenario that has only two AI sides, neither of which has a leader (or that are allied with each other), it will trigger this.  So that would be a simpler test case without all the fluff of the animals scenario, but I spent about 2 hours yesterday trying to figure out what is going on and verifying that the fluff is not the problem.
20140326 15:54:21< mattsc> So since that scenario is already there, I’ve just been using that.
20140326 15:54:40< mattsc> (and can be started from the CL, which makes it even more convenient, for me at least)
20140326 15:54:52< iceiceice> ok mattsc i think i know what the issue is
20140326 15:55:04-!- SigurdFD [~SigurdFD@24.154.98.89] has joined #wesnoth-dev
20140326 15:55:09< iceiceice> its basically a holdover bug from when we had human_ai and ai
20140326 15:55:19< iceiceice> apparently human_ai and ai were both ai controller types
20140326 15:55:26< mattsc> iceiceice: cool!  I’ll stay online and will be available for short comments, but otherwise can’t pay too much attention for the next couple hours.
20140326 15:55:41< mattsc> I see
20140326 15:55:51< iceiceice> but prior to my patch they would be different as far as whether you are an observer
20140326 15:56:11< iceiceice> i just assumed that that was an oversight, most of the time sides are not controlled by "ai" in the actual game
20140326 15:56:29< iceiceice> at least if you make it through the usual mp create dialog
20140326 15:56:56< iceiceice> it seems like what you want is that if your machine locally controls only ais, you become an observer
20140326 15:57:20< iceiceice> however in mp, if i decide to droid my side i shouldn't become an observer
20140326 15:57:39< happygrue> actually, that can be a good thing
20140326 15:57:43< gfgtdf> iceiceice: why ?
20140326 15:57:46< happygrue> that last line
20140326 15:58:03< iceiceice> i would consider it a regression
20140326 15:58:11< iceiceice> idk sometimes you want to droid your side
20140326 15:58:13< gfgtdf> iceiceice: i mean what else should happen to you if you driod your side?
20140326 15:58:29< iceiceice> the idea ist hat you may undroid your side later
20140326 15:58:36< happygrue> in general, droiding is kind of a dumb move in MP, but the idea is, you need to go do something for 10 minutes and don't want to slow up the game but you plan to lurk and come back.  So you give control to someone (or droid it)
20140326 15:58:43< iceiceice> sometimes if you play on a very large map and it doesnt particularly matter 
20140326 15:58:45< happygrue> and then you lurk and don't have to rejoin
20140326 15:58:48< iceiceice> you droid 
20140326 15:58:58< iceiceice> because its tedious to move lots of units around
20140326 15:59:02< iceiceice> and the droid will move them into battle
20140326 15:59:09< iceiceice> or sometimes if one player is just getting crushed
20140326 15:59:20< iceiceice> but refuses to give up
20140326 15:59:25< iceiceice> but is down like 3x in army value
20140326 15:59:31< iceiceice> the winning player may decide to droid his army for interest
20140326 15:59:35< iceiceice> to give the other player a chance
20140326 15:59:43< iceiceice> or to prove the point that he is very far ahead and can safely do this
20140326 15:59:56< iceiceice> idk it would be an unexpected regression i would say
20140326 16:00:17< happygrue> to become an observer after such a move?  That seems like the best outcome
20140326 16:00:23< happygrue> IMHO
20140326 16:00:33< iceiceice> no if you become an observer then you will have vision you shouldnt
20140326 16:00:36< vultraz> Droiding your side and becoming an observer is bad since you can do it for one turn and then check out the enemy
20140326 16:00:41< iceiceice> yeah
20140326 16:01:35< iceiceice> so i wonder if we can change the behavior of this victory when defeated function,
20140326 16:01:42-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140326 16:02:01< iceiceice> i mean there should be a way to configure a scenario so that it wont end unless the scenario WML says it is over
20140326 16:02:09< happygrue> ah, I see
20140326 16:03:05< gfgtdf> iceiceice: i think driding meand giving up controll on that side, maybe we neeed to implemtn a simlar contruct like shared ownership.
20140326 16:03:09< gfgtdf> droiding*
20140326 16:04:16< iceiceice> idk i think you should be able to droid and retain ownership
20140326 16:04:26< iceiceice> and also able to droid and give away, i think we can do these things right now
20140326 16:04:31< happygrue> Maybe it would be nice to have a way for observers to view only one team at a time?  Then we could lump such droided observers into the same vision they had before by default, and let them decide what to see after?
20140326 16:04:42< happygrue> could also be interesting to watch form only one point of view
20140326 16:04:47< happygrue> as a regular observer
20140326 16:05:05< happygrue> though that is a whole other feature really, just spitballing here.  :D
20140326 16:05:08< iceiceice> hehe :)
20140326 16:06:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140326 16:06:15-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140326 16:06:20< happygrue> well, replays can already to that, now that I think about it.  maybe the basic pieces are already there?
20140326 16:06:48< iceiceice> mattsc: do you rely on the behavior that in a scenario with two leaderless ai sides, it will end when one of them is destroyed?
20140326 16:06:51< gfgtdf> happygrue: how can i do that in replay ?
20140326 16:07:13< iceiceice> if an ai runs in a scenario with no opponents, and it didnt end, will the ai crash or something?
20140326 16:08:11< iceiceice> i'm thinking maybe we should overhaul the behavior of victory_when_defeated, i dont think theres actually anything wrong with is_observer right now
20140326 16:08:31< iceiceice> i mean sides have flags now, "has_leader" right?
20140326 16:08:43< iceiceice> we could make it check those and support mobs battles if so
20140326 16:09:28< mattsc> iceiceice: maybe I’m misunderstanding your question, but I think whether I (my AIs and scenarios) depend on it is irrelevant.
20140326 16:09:50-!- Incredible [~Incredibl@14.139.122.114] has joined #wesnoth-dev
20140326 16:10:17< mattsc> What matters is 1. that the behavior changed during the freeze period of 1.11 (which is not good unless it’s a bug fix) and 2. that it should be possible to have scenarios that only have leaderless AI sides.
20140326 16:10:28< happygrue> gfgtdf: I'd have to look at the buttons again, but isn't here a PoV button?
20140326 16:10:40< happygrue> you can select which team you want to view as, or the whole map IIRC
20140326 16:10:55< gfgtdf> 	happygrue: ah yes not i see it
20140326 16:10:58< gfgtdf> now*
20140326 16:11:06< iceiceice> mattsc: these controller type changes happened because i wanted to fix a bunch of bugs with reloading saved games
20140326 16:11:09< mattsc> iceiceice: Given that, I don’t think it matters (and I personally don’t care) how the defeat condition is triggered.
20140326 16:11:24< iceiceice> Soliton suggested that we get rid of the human_ai controller type, since frankly it should have been removed earlier
20140326 16:11:42< iceiceice> we are in the process of refactoring controller type things to make it make more sense...
20140326 16:11:44< mattsc> iceiceice: sure, and I am not arguing that point at all
20140326 16:12:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140326 16:12:15-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140326 16:12:34< iceiceice> ok. i think that the behavior did change but i dont think it broke feature freeze
20140326 16:12:41< mattsc> iceiceice: my main “complaint” is that I have a scenario that worked in 1.11.11 and does not work any more in 1.11.12.  If I have (at least) one scenario like that, I bet there are many others out there in UMC land.
20140326 16:12:46-!- ykanarev [~ykanarev@212.55.118.222] has quit [Quit: Leaving]
20140326 16:12:52< iceiceice> i dont doubt that there will be others
20140326 16:13:12< iceiceice> but the previous behavior was a bit crazy
20140326 16:13:26< iceiceice> your scenario only worked because of some bizarre distinction between human_ai and ai
20140326 16:13:37< mattsc> So I’m no authority on this, but I’d say that not allowing leaderless AI sides is both a feature change and a regression.
20140326 16:13:44< iceiceice> i think we should allow it,
20140326 16:14:10< iceiceice> i think that when we added the "has_leader" flag in sides it should also have factored into the victory when defeated check
20140326 16:14:20< iceiceice> i propose we fix that "bug" which afaik would fix your scenario
20140326 16:14:38< iceiceice> assuming that your sides have "has_leader=no" in their definitions 
20140326 16:14:39< mattsc> iceiceice: note that I am exclusively arguing from the user (UMC author) side in this.  I personally do not care very much at all how this is implemented.
20140326 16:14:59< vultraz> mattsc: leaderless ai sides are necessary for cutscenes and such
20140326 16:15:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140326 16:15:23< mattsc> iceiceice They have ‘no_leader=yes’ in their definitions.
20140326 16:15:32< iceiceice> ok
20140326 16:15:36< mattsc> vultraz: yes, I’d assume so
20140326 16:15:40< iceiceice> so this is basically the "behavior_change" that i am proposing
20140326 16:15:54< vultraz> or stuff like spawner sides or roaming animals..
20140326 16:16:00< iceiceice> previously your animals scenario didn't end because while "found_player" was no, since it didnt find any opposing leaders,
20140326 16:16:06< iceiceice> it got confused by controller types and thought it was an observer
20140326 16:16:20< iceiceice> you aren't an observer, the local human player owns all of the sides in that game :p
20140326 16:16:32< mattsc> vultraz: notice that this problem only happens if there is also no human controlled side, so it is probably not too wide-spread
20140326 16:16:34< iceiceice> now we fixed the observer bheavior
20140326 16:16:37< iceiceice> with my patch
20140326 16:16:39< mattsc> s/notice/note
20140326 16:16:40< iceiceice> but it broke your scenario
20140326 16:16:47< iceiceice> so i want to fix the found_player part also
20140326 16:16:50< vultraz> oh ok
20140326 16:16:51< iceiceice> which will fix it again
20140326 16:17:15-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140326 16:17:17< mattsc> iceiceice: that sounds good to me
20140326 16:18:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20140326 16:19:23< mattsc> iceiceice: I hope you understand that I’m not arguing that any of your changes are bad in itself.  I just want my AI vs. AI battle scenarios back without having to put a hidden leader into a corner of the map somewhere (or some other hack like that).  :)
20140326 16:20:10< iceiceice> i just want to fix bugs :)
20140326 16:20:11-!- cib0 [~cib@p5DD21A9C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140326 16:22:06< mattsc> iceiceice: Sounds good to me.  I went on an exterminating spree for a while last fall, it was fun.  But right now I mostly just want to get Fred to stop being so damned stupid.  (Well, and add some more features to the MAIs.)
20140326 16:22:15-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140326 16:27:55-!- Incredible [~Incredibl@14.139.122.114] has quit [Ping timeout: 246 seconds]
20140326 16:33:21-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140326 16:34:54< SigurdFD> iceiceice: were you were the one who added the 'Warning: This is a mutliplayer scenario..."?
20140326 16:35:03< iceiceice> yes
20140326 16:35:19< iceiceice> SigurdFD: i was just about to write you on forums,
20140326 16:35:33< iceiceice> i wonder if this generator assert failure isn't related to 21808,
20140326 16:35:44< SigurdFD> is there a gna bug # or other instructions for reproducing the bugs caused by not following the instructions?
20140326 16:35:49-!- Kexoth [~kex@89.205.75.19] has quit []
20140326 16:35:58< SigurdFD> there's a spot in the commit history I want to check
20140326 16:37:44< iceiceice> so i'm not intending the warning as some political thing to declare some bugs as not bugs
20140326 16:37:51< iceiceice> its to help users avoid bugs,
20140326 16:38:03< iceiceice> there are two separate code paths, one for loading SP and one for MP
20140326 16:38:12< iceiceice> i didnt learn this until i wasted some time on it, so i added the warning
20140326 16:38:13< SigurdFD> ok
20140326 16:39:00< iceiceice> what do you mean by "theres a spot in the commit history you want to check"
20140326 16:39:14< iceiceice> you mean like from before the warning?
20140326 16:40:18< iceiceice> i will say this, when i added the warning Ivanovic wrote that "it would be much better if instead of giving a warning, we just do the right thing"
20140326 16:40:27< iceiceice> but i dont know enough about that part of the code to do that right now
20140326 16:40:55< iceiceice> anyways i guess we hope to merge the codepaths into one eventually
20140326 16:41:45< iceiceice> SigurdFD: regarding this generator assertion failure on reloaded games,
20140326 16:41:53< iceiceice> you might also look at this recent bugfix: https://github.com/wesnoth/wesnoth/commit/fa5b916bf1240c20d3faccb4f3be59c00003433b
20140326 16:41:58< SigurdFD> I'm thinking that #20895, because of the differing behavior for which path a start of scenario save is loaded from, is related to the warning
20140326 16:42:27< iceiceice> 21808 was a recent bug -- since 1.11.7 or something, it wasn't possible for observers to join a reloaded game at any point
20140326 16:42:38< iceiceice> because theres some issue with how reloaded games are configured
20140326 16:42:57< iceiceice> the commit i mentioned puts on a bandaid which makes sure to configure the mp parameters and the observer permissions etc.
20140326 16:42:58< SigurdFD> already looked at 21808, it's fix doesn't do anything for 20895
20140326 16:43:19< iceiceice> what i'm wondering is if theres something wrong with the configuration for the random map generator, and if we could make the bandaid bigger
20140326 16:43:23< iceiceice> but its just a guess i dont know
20140326 16:44:15< iceiceice> afk, be back in a bit
20140326 16:44:17-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Quit: Leaving]
20140326 16:44:58< SigurdFD> ok, a bigger bandaid sounds promising
20140326 16:47:17-!- trademark [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has quit [Ping timeout: 252 seconds]
20140326 16:47:44-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Read error: Connection reset by peer]
20140326 16:47:46-!- thunders1ruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has joined #wesnoth-dev
20140326 17:06:11-!- werlley [~werlley@179.124.130.66] has joined #wesnoth-dev
20140326 17:14:56-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 265 seconds]
20140326 17:15:20-!- Dugi [93fbd156@gateway/web/freenode/ip.147.251.209.86] has joined #wesnoth-dev
20140326 17:15:33-!- ykanarev [~ykanarev@78.81.70.234] has joined #wesnoth-dev
20140326 17:15:39-!- Ivanovic [~ivanovic@x2f49ca7.dyn.telefonica.de] has joined #wesnoth-dev
20140326 17:15:39-!- Ivanovic [~ivanovic@x2f49ca7.dyn.telefonica.de] has quit [Changing host]
20140326 17:15:39-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20140326 17:22:06-!- thunders1ruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Quit: leaving]
20140326 17:22:29-!- RiftWalker [~RiftWalke@129.59.115.25] has joined #wesnoth-dev
20140326 17:24:31-!- werlley [~werlley@179.124.130.66] has quit [Remote host closed the connection]
20140326 17:31:27-!- sachith500 [~kvirc@112.135.156.253] has joined #wesnoth-dev
20140326 17:33:15-!- iceiceice [~chris@207-237-132-90.ny.subnet.cable.rcn.com] has joined #wesnoth-dev
20140326 17:33:25< iceiceice> do we officially support sides with multiple leaders?
20140326 17:33:32< shadowm> Yes.
20140326 17:34:26< iceiceice> just checking
20140326 17:38:31-!- iwaim [~iwaim@2001:2c0:40e:2002:0:4:14:80] has quit [Ping timeout: 246 seconds]
20140326 17:40:05< AI0867> 01:03 < gfgtdf> AI0867: you said you also have concerns about implementing the Determinisitc mode for SP ? <-- not really?
20140326 17:46:01< gfgtdf> AI0867: i remembered you saing something like "Options are bad",
20140326 17:47:31< iceiceice> ok this is pointless whining but i really wish we had named the field "has_leader" and not "no_leader"...
20140326 17:47:48< iceiceice> now i look at the code and it says "if we don't not have no leader..." and i feel like i am transported to the deep south in the 50s or something
20140326 17:48:12< gfgtdf> and i thought that was about implementing teh optional deterministic mode for sp.
20140326 17:48:16< iceiceice> ok i guess the code is onyl a double negative but still
20140326 17:48:57< RiftWalker> Does anyone know which parts of an SP campaign might not work properly if loaded as an mp campaign? So far, I can see that playmp_controller is loaded, but otherwise most things seem to work.
20140326 17:49:41< Dugi> RiftWalker: Options in messages may cause trouble with OoS.
20140326 17:50:23< Dugi> RiftWalker: And they might have been adressed only to a single side.
20140326 17:50:42< gfgtdf> Dugi: i plan to change that.
20140326 17:51:05-!- neXyon [~neXyon@85-127-75-96.dynamic.xdsl-line.inode.at] has quit [Quit: bye]
20140326 17:51:06< vultraz> I thought gfgtdf and EliDupree were working on fiixing that
20140326 17:51:35-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140326 17:51:44< EliDupree> Dugi: I believe this is false
20140326 17:51:50< Dugi> Another problem I can think of is advancing during another guy's turn, single player campaign might assume that the player makes the choice.
20140326 17:51:50< EliDupree> Message options are fine in MP
20140326 17:52:18< vultraz> Dugi: that has already been brought up
20140326 17:52:31< Dugi> Okay, then, I didn't know.
20140326 17:52:36< RiftWalker> Right now I'm mostly concerned with things that would work if loaded in sp, but not in mp
20140326 17:52:51< vultraz> RiftWalker: what about UMC GUI2 dialogs
20140326 17:53:18< vultraz> there is wesnoth.synchronize_choice, but I believe I had some issues with that...
20140326 17:53:20< EliDupree> Yeah, that and checking/altering controller=
20140326 17:53:23< RiftWalker> Which seem to be minimal. As for off-turn advancing, I understand that local players in mp can choose
20140326 17:53:24< gfgtdf> vultraz: GUI 2 dialogs are moaly involed via geT_user_choice andbehind teh scenes i's teh same code as masseage options
20140326 17:53:40-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140326 17:53:48< gfgtdf> via wesnoth.snc_choice
20140326 17:53:51< gfgtdf> sync
20140326 17:53:59< RiftWalker> vultraz: Haven't checked. Know of a quick example?
20140326 17:54:00< vultraz> I don't use sync choice
20140326 17:54:15< gfgtdf> vultraz: you should 
20140326 17:54:21< Dugi> Have you figured out what do do if more campaigns have different units with the same names? They cause trouble in multiplayer, but are fine in single player because of different preprocessor conditions.
20140326 17:54:22< vultraz> I had problems with it
20140326 17:54:26< EliDupree> ...it's unnecessary in SP
20140326 17:54:38< vultraz> and since I was creating something for SP I dumped it
20140326 17:54:40< gfgtdf> EliDupree: if you want your replays to work then it's not
20140326 17:54:44< RiftWalker> Dugi: I'm still trying to figure that out.
20140326 17:54:44< EliDupree> I know how it works though. I can help you.
20140326 17:54:45< vultraz> however, if it will now become necessary
20140326 17:55:28< gfgtdf> Dugi: you mean unit_types ?
20140326 17:55:33< gfgtdf> unit types
20140326 17:55:37< Dugi> gfgtdf: Yes.
20140326 17:55:43< RiftWalker> Dugi: Probably going to figure out a way to load sections of content late
20140326 17:56:18< gfgtdf> i tihnk teh plan was to mrove the MULTIPLAYER define for add on specifics defines just liek sp scenarios ?
20140326 17:56:21< gfgtdf> think the*
20140326 17:56:28< Dugi> RiftWalker: Looks like there is no other way, but I am quite a newbie to wesnoth's source code.
20140326 17:56:34< vultraz> that was my idea, yes
20140326 17:56:44< vultraz> RiftWalker: my umc campaign Shadows of Deception, shadowm's After the Storm and Invasion from the Unknown, and dugi's Legend of the Invincibles are the only umc I know of to use custom gui2 dialogs
20140326 17:56:56< vultraz> mine, I believe, are more complicated
20140326 17:57:11< gfgtdf> vultraz: mine used GUI2 dialogs too :)
20140326 17:57:41< Dugi> vultraz: Legend of the Invincibles doesn't use gui2 dialogs, I tried to stay out of lua for (quite absurd) didacting reasons.
20140326 17:57:53< RiftWalker> vultraz: I'll definately test it out, but I can't see why it wouldn't work.
20140326 17:58:13< gfgtdf> *
20140326 17:58:23< vultraz> Dugi: oh, I thought it did. My bad
20140326 17:58:25< Dugi> vultraz: I used them in World of Wesnoth, but that one is far from finished because the scenario-maker is busy.
20140326 17:58:49< vultraz> Well if anyone's interested, my GUI2 dialogs are here https://github.com/Vultraz/NX-RPG/tree/master/lua/gui
20140326 17:59:17< RiftWalker> I'll bbl
20140326 17:59:25< gfgtdf> bbl ?
20140326 17:59:32< vultraz> I believe the inventory one was the one that had issues with sync choice
20140326 17:59:36< vultraz> gfgtdf: Be Back Later
20140326 17:59:44< Dugi> Quick question: If I need something to run periodically, like every 6 minutes (precision isn't important), where should I place that thing?
20140326 18:00:20< gfgtdf> we currently use just one thread of mose of things.
20140326 18:00:31< gfgtdf> maybe in play slice or simlar
20140326 18:00:31< shadowm> You first should ask yourself why it needs to run periodically and what alternatives there might be.
20140326 18:01:12< Dugi> shadowm: No alternatives, it's fabi's suggestion to keep track what add-ons is the player playing for how long and upload the statistics.
20140326 18:01:32< gfgtdf> Dugi: just log when he started and when he quits ?
20140326 18:02:32< Dugi> gfgtdf: Lol, why the hell didn't I think of that. So I'll just place it in playsingle_controller's constructor and destructor.
20140326 18:02:48< Dugi> gfgtdf: Do you think that will work?
20140326 18:03:38-!- sachith500 [~kvirc@112.135.156.253] has quit [Ping timeout: 240 seconds]
20140326 18:03:44-!- RiftWalker [~RiftWalke@129.59.115.25] has quit [Ping timeout: 252 seconds]
20140326 18:03:57< gfgtdf> Dugi: idk i never had to work with playsinges destructor, but i would guess yes.
20140326 18:04:43< Dugi> gfgtdf: I'll put there a std::cout << something to see if it runs.
20140326 18:05:22< gfgtdf> we normal use LOG_NG or similar instead of  std::cout
20140326 18:06:10< Dugi> That's why I use std::cout, I can just search the files to find where I have forgotten to delete old debugging logs.
20140326 18:06:16< shadowm> For quick debugging checks taht will not be pushed upstream you should use std::cerr, not std::cout.
20140326 18:07:15< Dugi> shadowm: Is there any reason for that? I am deleting these lines after finishing anyway.
20140326 18:07:37< shadowm> std::cout is a buffered stream for fd 1 (stdout), so messages may come out from the other end out of order if at all (which is a major problem when inspecting a crash site).
20140326 18:08:33< gfgtdf> Dugi: i think people won't beat you if you accidently left a LOG_NG if it doesn't produce spam.
20140326 18:08:34< shadowm> Out of order relative to messages written by the standard logging facilities used here, that is, which use std::cerr (fd 2 a.k.a. stderr).
20140326 18:08:51< Dugi> shadowm: Yes, that makes sense. I never thought of that.
20140326 18:08:56< shadowm> std::cerr is unbuffered so things are written out immediately.
20140326 18:09:16-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140326 18:10:26< Dugi> gfgtdf: By the way, playsingle's destructor fires exactly when I leave a game, that's exactly what I wanted.
20140326 18:10:47< Dugi> shadowm: I didn't know that.
20140326 18:11:11-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20140326 18:15:51-!- lipkab [~lipk@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140326 18:22:58< iceiceice> Dugi i think instead of using the destructors
20140326 18:23:01< iceiceice> use like ...
20140326 18:23:03< iceiceice> game_controller
20140326 18:23:07-!- sachith500 [~kvirc@112.135.156.253] has joined #wesnoth-dev
20140326 18:23:07< iceiceice> or something more basic
20140326 18:23:19< iceiceice> idk maybe the destructor is the way to go
20140326 18:23:26< iceiceice> but it seems ore complicated than necessary
20140326 18:23:45< iceiceice> idk consider your options anyways
20140326 18:24:15< iceiceice> afaik play_campaign.cpp is also a good candidate if you want to track individual scenarios
20140326 18:30:57< Dugi> iceiceice: I don't need to track individual scenarios, and I need to track also multiplayer scenarios, eras and modifications. But I think I know how can I do that now.
20140326 18:32:06< gfgtdf> did you also have problems with the movement orbs with the current master ?
20140326 18:34:30< iceiceice> i've had some problems with missing orbs
20140326 18:34:40< iceiceice> mainly related to blindfold
20140326 18:34:56< iceiceice> i also think that there is a regression now in that statues now have "red" enemy orbs i guess
20140326 18:35:12< iceiceice> idk what exactly you mean gfgtdf
20140326 18:35:46< gfgtdf> all movement orbs are red/pink no matter wether the units ca move cannot move or are enemies
20140326 18:35:55< iceiceice> anyone: i'm going to push a fix very soon i think for the "victory_when_enemies_defeated" flag
20140326 18:36:06< iceiceice> does anyone know of any core scenarios that use this that I can test?
20140326 18:36:35< iceiceice> the patch involves slightly changing the logic of check_victory in play_controller.cpp, so it potentially affects SP as well as MP
20140326 18:36:45< shadowm> Fix for what about it?
20140326 18:36:52-!- lipkab [~lipk@host-91-147-212-189.biatv.hu] has quit [Quit: WeeChat 0.4.3]
20140326 18:36:52< iceiceice> theres a logic bug
20140326 18:37:09< iceiceice> so basically sides that have "no_leader = yes" are still considered defeated
20140326 18:37:18< iceiceice> if they dont have a leader
20140326 18:37:21< shadowm> Also, `fgrep -RI victory_when_enemies_defeated data/campaigns`.
20140326 18:37:28< iceiceice> thx
20140326 18:37:41< iceiceice> you can check earlier in logs if you want to see how we discovered this
20140326 18:39:09< iceiceice> hmm ok after grepping i'm now very nervous to push this ><
20140326 18:40:19-!- exciton_ [chuck-the-@77.51.49.102] has joined #wesnoth-dev
20140326 18:40:22< iceiceice> going to do quite a bit of testing i think... theres a lot of campaign scenarios here that are a lot more important than these micro_ai scenarios...
20140326 18:40:43-!- sachith500 [~kvirc@112.135.156.253] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140326 18:42:19< iceiceice> although i guess we discussed that the impact should be very limited...
20140326 18:42:26< iceiceice> i think i need to play some campaigns now anyways though ><
20140326 18:43:22-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has quit [Quit: leaving]
20140326 18:44:07-!- ALourenco_ [c189db30@gateway/web/freenode/ip.193.137.219.48] has joined #wesnoth-dev
20140326 18:44:08-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 240 seconds]
20140326 18:44:57< ALourenco_> Hello
20140326 18:45:21< gfgtdf> hi
20140326 18:48:23< ALourenco_> mordant: are you here?
20140326 18:48:38-!- exciton_ [chuck-the-@77.51.49.102] has quit [Read error: Connection reset by peer]
20140326 18:48:48< Dugi> It is mordante, not mordant, and he's not here.
20140326 18:48:51-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20140326 18:49:48< shadowm> If you leave your messages here anyway, he will read them later when he reads the logs.
20140326 18:51:06< ALourenco_> ok ty 
20140326 18:54:54-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140326 19:03:20< iceiceice> vultraz, gfgtdf, mattsc, anyone else with an opinion in the earlier discussion: i know we said earlier that the number of scenarios with no human players is very low.
20140326 19:03:43< iceiceice> i'm 99% sure this PR will correctly fix the bug we talked about
20140326 19:03:44< iceiceice> https://github.com/wesnoth/wesnoth/pull/133
20140326 19:03:48< iceiceice> and it works in simple tests
20140326 19:03:54-!- TooLmaN [~TooLmaN@mx1.thomsonplastics.com] has quit [Quit: Off to save the world!]
20140326 19:04:10< iceiceice> but there are apparently a lot of campaigns that use victory_when_enemies_defeated...
20140326 19:04:22< iceiceice> if anyone can think of a way to be sure this doesn't break some obscure campaign i am all ears
20140326 19:09:47-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140326 19:19:58-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140326 19:22:15< AI0867> 02:56 < _8680_> I could return 0 if `N` is signed and `n < 0`, but I believe I’d need C++11 to check whether `N` is signed. <-- std::numeric_limits::is_signed is present in C++98
20140326 19:23:44< AI0867> and I wasn't asking you to provide non-twos-complement compatibility, I was just asking if this will actually return 0 for N < 0 with each implementation
20140326 19:25:05< AI0867> 06:06 < iceiceice> question: how do i delete a dead branch on wesnoth? <-- like all changes to a remote repo, you use git push. The manpage can tell you the exact syntax
20140326 19:26:02< iceiceice> thanks. i guess i find that slightly counter intuitive
20140326 19:27:11-!- wesbot changed the topic of #wesnoth-dev to: string+feature freeze active on 1.12 | 232 bugs, 352 feature requests, 28 patches | Logs: http://irclogs.wesnoth.org | Alternate logs: http://wesnoth.debian.net | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20140326 19:28:56< Ivanovic> iceiceice: great to hear that i said something this wise!
20140326 19:29:31< iceiceice> yeah i hope that is all resolved some day :)
20140326 19:31:15-!- Spoffy [~chatzilla@152.78.175.8] has joined #wesnoth-dev
20140326 19:33:03-!- RiftWalker [~RiftWalke@129.59.115.25] has joined #wesnoth-dev
20140326 19:33:25-!- lipkab [~lipk@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140326 19:34:15-!- lipkab [~lipk@host-91-147-212-189.biatv.hu] has quit [Client Quit]
20140326 19:38:33-!- RiftWalk1r [~RiftWalke@129.59.115.25] has joined #wesnoth-dev
20140326 19:38:57-!- RiftWalk1r [~RiftWalke@129.59.115.25] has quit [Client Quit]
20140326 19:39:11-!- RiftWalk1r [~RiftWalke@129.59.115.25] has joined #wesnoth-dev
20140326 19:39:29< RiftWalk1r> exit
20140326 19:39:32-!- RiftWalk1r [~RiftWalke@129.59.115.25] has quit [Client Quit]
20140326 19:39:51-!- RiftWalk1r [~RiftWalke@129.59.115.25] has joined #wesnoth-dev
20140326 19:41:38-!- RiftWalker [~RiftWalke@129.59.115.25] has quit [Ping timeout: 252 seconds]
20140326 19:42:45< AI0867> _8680_: also, do you think we need both bit_width<T>() and bit_width<T>(T t)? What usecase does the second have?
20140326 19:43:50< RiftWalk1r> hey vultraz
20140326 19:44:30-!- RiftWalk1r [~RiftWalke@129.59.115.25] has quit [Client Quit]
20140326 19:44:49-!- RiftWalker [~RiftWalke@129.59.115.25] has joined #wesnoth-dev
20140326 19:47:49< AI0867> 18:46 < gfgtdf> AI0867: i remembered you saing something like "Options are bad", <-- right, that's the standard reply to "just make it an option". it was more in reply to the possible optionality than the change itself
20140326 19:50:12< _8680_> AI0867: I have no experience with non–two’s-complement systems; I don’t know what would happen with `n < 0`.
20140326 19:50:16< _8680_> `bit_width<T>(T x)` is just for convenience, in case `T` is lengthy.
20140326 19:51:09< _8680_> s/.$/ and `x` isn’t./
20140326 19:52:07-!- SigurdFD [~SigurdFD@24.154.98.89] has quit []
20140326 19:53:28< _8680_> Once #128 lands, I can add the `n < 0` check, and you can delete `bit_width<T>(T x)` if you like (I don’t believe I used it anywhere where `T` is lengthier than `x`).
20140326 19:53:59< _8680_> (Or I could delete it, if so ordered.)
20140326 20:01:05< Dugi> Guys, I think I have finished the stuff regarding the add-on ratings, because I don't have commit access, who should I sent it to?
20140326 20:02:08< _8680_> Dugi: File a GitHub pull request?
20140326 20:02:32< Dugi> How do I do that?
20140326 20:02:34< _8680_> Dugi: Have you forked the repository on GitHub?
20140326 20:02:42< Dugi> Nope, I haven't forked it.
20140326 20:03:06< _8680_> Your work is in a local topic branch?
20140326 20:03:26< RiftWalker> Dugi: http://wiki.wesnoth.org/Git_for_Wesnoth_Crash_Course
20140326 20:03:27< Dugi> Probably.
20140326 20:04:25< _8680_> Dugi: Do you have a local clone of the Wesnoth repository on GitHub?
20140326 20:04:33< Dugi> Yes, I do.
20140326 20:04:41< Dugi> I have done all the changes there.
20140326 20:04:52< _8680_> Did you create a new branch for your changes?
20140326 20:05:08< Dugi> No.
20140326 20:05:43-!- neXyon [~neXyon@85-127-75-96.dynamic.xdsl-line.inode.at] has joined #wesnoth-dev
20140326 20:05:49< _8680_> Okay, you should have, but it’s easy enough to fix if your changes haven’t been published yet.
20140326 20:06:09< _8680_> Have you committed your work in your local repository?
20140326 20:06:13< Dugi> Okay, what should I do?
20140326 20:10:58< _8680_> Dugi: Have you committed your work?
20140326 20:11:28< Dugi> I haven't committed it, I don't have commit access.
20140326 20:11:53-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has joined #wesnoth-dev
20140326 20:14:15< _8680_> With SVN, there was one central repository; with Git, each clone is a full repository, and you can do whatever you want to your own repository. You may not have *push* access to the upstream repository on GitHub, but you can still commit to your own local repository.
20140326 20:14:37< _8680_> But anyway, if you haven’t committed yet, that makes this easier.
20140326 20:14:39< Dugi> Ah, I'll try that. I'll see if I have a local repository.
20140326 20:15:06< _8680_> If you cloned the upstream repository, then you have a local repository.
20140326 20:15:44< _8680_> If you clone into `wesnoth`, then the repository is in `wesnoth/.git` (the rest of `wesnoth` is the “working tree”).
20140326 20:17:16< AI0867> 20:50 < _8680_> AI0867: I have no experience with non–two’s-complement systems; I don’t know what would happen with `n < 0`. <-- well, one's complement and sign-and-magnitude have the same result as two's complement, but there are other possible schemes that don't
20140326 20:17:26< Dugi> Seems I'll need to have a githut account for first :D
20140326 20:17:48< AI0867> question is whether anyone could reasonably as for the number of leading zeros of a signed int anyway
20140326 20:18:19-!- Jetrel [~Jetrel@c-75-73-180-126.hsd1.mn.comcast.net] has quit [Read error: Connection reset by peer]
20140326 20:19:18< _8680_> Since you haven’t committed yet, run `git checkout -b dugi/some-stuff` (change ‘some-stuff’ to whatever it is you’re working on). This will create a new topic branch, that you can then commit your changes onto. (A ‘topic branch’ is a branch made for one specific feature, issue, or such, rather than a ‘long-running branch’ like `master`.)
20140326 20:19:48-!- Jetrel [~Jetrel@c-75-73-180-126.hsd1.mn.comcast.net] has joined #wesnoth-dev
20140326 20:20:15< _8680_> To be clear, the commands don’t distinguish between long-running branches and topic branches — the distinction is only in how they’re used.
20140326 20:22:49< RiftWalker> Soliton: I have a couple of questions regarding add-on loading. Can you help me?
20140326 20:23:49< Dugi> _8680_: When I try to upload it, it reports error 403.
20140326 20:24:09< _8680_> When you try to upload what to what?
20140326 20:24:30-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140326 20:25:20< Dugi> I just used git push, don't know what was I doing if it was wrong.
20140326 20:25:44< _8680_> What is the full command that you ran?
20140326 20:26:22< Dugi> git push
20140326 20:26:39< Dugi> I am not very familiar with git and all the repo cloning stuff.
20140326 20:27:05< _8680_> Okay, please pastebin the output.
20140326 20:27:11< _8680_> You shouldn’t be pushing yet though.
20140326 20:27:21< Dugi> What output?
20140326 20:27:35< _8680_> The output of `git push`, that you said errored.
20140326 20:28:00< Dugi> Here: http://pastebin.com/xzddMDuk
20140326 20:29:01< _8680_> Okay, you were pushing to the upstream repository, when you should be pushing to a fork.
20140326 20:29:12< Dugi> Okay, how do I push it to a fork?
20140326 20:29:37< _8680_> You don’t have anything you can push yet.
20140326 20:29:42< _8680_> Once you’ve created the topic branch, commit your changes: `git add <files you changed...>`, then `git commit -v` (the `-v` switch shows you your changes, so you can review them one last time before committing them).
20140326 20:30:02< _8680_> See also <http://git-scm.com/book/ch5-2.html#Commit-Guidelines>.
20140326 20:30:44< _8680_> Especially the section on commit messages.
20140326 20:33:07-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Remote host closed the connection]
20140326 20:33:08-!- ALourenco_ [c189db30@gateway/web/freenode/ip.193.137.219.48] has quit [Ping timeout: 245 seconds]
20140326 20:33:53< Dugi> I have tried the commit command and wrote a description, but I don't know if it has acutally done something.
20140326 20:34:01< _8680_> To push to a fork, first fork the upstream repository by going to <https://github.com/wesnoth/wesnoth> and clicking the “Fork” button, then add your fork as a remote of your local repository (`git remote add fork https://github.com/Dugy/wesnoth`).
20140326 20:34:15< _8680_> Then `git push fork dugi/some-stuff`.
20140326 20:34:48< _8680_> Dugi: Does `git log` show your commit?
20140326 20:35:25< Dugi> It shows something.
20140326 20:36:12< Dugi> It shows this: http://pastebin.com/ZXGH2pug
20140326 20:36:41< thunderstruck> RiftWalker: Any particular reason why you specifically ask Soliton about this? Others might also be able to answer some of your questions.
20140326 20:36:57-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140326 20:37:38< _8680_> Dugi: Okay, you committed successfully. However, your commit message is poorly formatted; see the commit guidelines I linked above.
20140326 20:38:10< Dugi> _8680_: I wasn't really believing that it would work, so I didn't bother writing something better.
20140326 20:38:49< Dugi> _8680_: Anyway, if it's comitted successfully, does it mean that the developers will see it?
20140326 20:39:02< _8680_> Not until you push and file a pull request.
20140326 20:40:31< _8680_> I advise fixing up your commit message, which can be done with `git commit --amend`. Note that one should avoid changing commits that have already been published (it’s messy), but changing commits that haven’t been published is fine.
20140326 20:40:50< _8680_> A commit message consists of a summary line and a message body, like an email message. The message body should be line-wrapped to 72 columns; according to the Git book, the summary line should be limited to 50 columns.
20140326 20:41:12< Dugi> Ah, so I have to use the git remote add fork https://github.com/Dugy/wesnoth command after fixing the commit message?
20140326 20:42:24< _8680_> Run that command before pushing to your fork. It defines a remote repository named ‘fork’, which you can then push to (and fetch from, but you wouldn’t do that with a fork).
20140326 20:42:57< _8680_> The message body should describe and explain all changes made by the commit as fully as possible. The summary line should summarize the message body.
20140326 20:43:29< _8680_> The summary line should be written as a sentence, except that it should not include a terminating full stop.
20140326 20:45:01< RiftWalker> thunderstruck: No good reason, I suppose. I'm wondering if instead of loading all add-ons and their content with load_addon_cfg() we couldn't just load the metadata by loading (and maybe expanding) _info.cfg for each addon instead.
20140326 20:45:41< RiftWalker> and then save the actual add-on loading for when an add-on is selected and the game is loaded.
20140326 20:46:59< thunderstruck> RiftWalker: _info.cfg won't give you enough information about an add-on
20140326 20:47:21< thunderstruck> I believe that add-ons suppose to work even without that file, IIRC
20140326 20:48:44< thunderstruck> RiftWalker: Anyway, this approach would be similar to the one which is already used for campaigns
20140326 20:48:49< Dugi> _8680_: Done that, but I see no fork repository at the moment.
20140326 20:49:08< RiftWalker> It seems to me we only need enough data to be able to a) know when and where an add-on can be selected, and b) load the add-on from file when we want to
20140326 20:49:15< thunderstruck> I.e. keep metadata in _main.cfg and add define around the actual data
20140326 20:49:46< thunderstruck> RiftWalker: I think there might be a problem with add-on dependencies
20140326 20:49:53< RiftWalker> Wouldn't that require updating all existing add-ons?
20140326 20:50:18< RiftWalker> In _info.cfg we have dependency list, title, and type
20140326 20:50:23< Dugi> _8680_: According to my command line, the repository exists, but according to the website, I have no repositories and no contribs.
20140326 20:50:56< RiftWalker> with that plus the file location, what else would we need?
20140326 20:51:18< RiftWalker> assuming that our _info.cfg is well-formed and correct, that is
20140326 20:51:20< _8680_> Dugi: Did you go to <https://github.com/wesnoth/wesnoth> and click “Fork”?
20140326 20:51:46< Dugi> _8680_: Nope, that is the problem, probably.
20140326 20:52:48< thunderstruck> RiftWalker: I don't think you can just go and load some individual files
20140326 20:53:11< thunderstruck> And _info.cfg does not necessary contain that information
20140326 20:53:15< thunderstruck> it might just not exist
20140326 20:53:30< _8680_> Once you’ve (a) forked the repository on the GitHub website and (b) run `git remote add […]`, you can then push your commit up to your fork: `git push fork dugi/some-stuff` (replacing ‘some-stuff’ as before).
20140326 20:53:42< RiftWalker> From what I understand, It's automatically generated, so it should. Maybe not.
20140326 20:54:09< RiftWalker> I guess ideally we need something similar to [campaign]
20140326 20:54:35< thunderstruck> RiftWalker: The point I'm trying to make is that _info.cfg approach is basically similar to define approach.
20140326 20:54:46< RiftWalker> which i believe was what zaroth was going for with [scenario_metadata]
20140326 20:54:48< thunderstruck> RiftWalker: And define approach is already proved to be working.
20140326 20:55:45< RiftWalker> Right. I was hoping that this would work as a solution as-is, without requiring current umc to be updated.
20140326 20:56:24< thunderstruck> RiftWalker: So you were right. _info.cfg is actuall auto generated.
20140326 20:57:18< thunderstruck> Although it might contain too little information at least in some cases (I just opened some _info.cfg in my add-on folder)
20140326 20:58:21< RiftWalker> thunderstruck: What extra information might we need?
20140326 20:58:43< thunderstruck> RiftWalker: add-on's id
20140326 20:58:46< RiftWalker> thunderstruck: I wonder how it's generated..
20140326 20:58:59< RiftWalker> gm
20140326 20:59:01< RiftWalker> hmm*
20140326 20:59:13< Dugi> _8680_: I have used the git push fork command, but it just stands still, seems to be doing nothing.
20140326 20:59:41< Dugi> thunderstruck: The add-on's id is the name of the folder it is in.
20140326 21:00:00< RiftWalker> oo
20140326 21:00:09< _8680_> Dugi: Please pastebin the output of `git push fork […]`.
20140326 21:00:54< Dugi> _8680_: Here: http://pastebin.com/t5x3kXzt
20140326 21:01:03< thunderstruck> RiftWalker: If you're worried about breaking existing UMC with defines, you could keep support existing add-ons with MULTIPLAYER define.
20140326 21:01:11< thunderstruck> And load them only for the actual multiplayer.
20140326 21:01:36< thunderstruck> So, SP namespace would not be affected.
20140326 21:01:52< _8680_> Dugi: That’s all? You entered your password, and then the command just exited?
20140326 21:02:03< RiftWalker> Dugi, thunderstruck: in that case, if we can grab the folder we're in when scanning through the user add-on folder, thus getting id and our location to load later at once.
20140326 21:02:12< Dugi> _8680_: It didn't exit, it just does nothing.
20140326 21:02:45< RiftWalker> thunderstruck: I'm looking at an era right now, which has #ifdef MULTIPLAYER guards.
20140326 21:02:52< thunderstruck> RiftWalker: possibly
20140326 21:03:29< Dugi> RiftWalker: It is read and paired with campaign/era/scenario/whatever's names in config in the version I am just trying to get to github for a pull request.
20140326 21:03:41< thunderstruck> RiftWalker: Although I'm not sure how that would work.
20140326 21:03:57< thunderstruck> RiftWalker: _main.cfg should be skipped somehow?
20140326 21:04:06< thunderstruck> (from parsing)
20140326 21:04:06< iceiceice> Dugi: how did you configure your remotes?
20140326 21:04:18< iceiceice> can you show us like git remote -v or something?
20140326 21:04:48< Dugi> iceiceice: I am just trying to get it to the git repo, so I can't show it to you. I don't understand the first question.
20140326 21:05:06< iceiceice> i mean, can you type "git remote -v" and put the results in paste bin
20140326 21:05:24< RiftWalker> thunderstruck: Looking at the code for game_config_manager::load_addons_cfg, it goes through and loads all userdir/*/_main.cfg and userdir/*.cfg
20140326 21:05:59< RiftWalker> for the *.cfg (single-file addons) this wouldn't really help
20140326 21:06:18< Dugi> iceiceice: I have done a lot of changes, it'll be hard to find, but you can see it here if you can find its parts: http://pastebin.com/0jea3Qxy
20140326 21:06:30< RiftWalker> but for large add-ons, instead of loading _main, you could load _info
20140326 21:06:52< RiftWalker> then you would need corresponding code to load the corresponding _main when appropriate
20140326 21:07:10< iceiceice> Dugi: i only want to see the command line results of "git remote -v", not your diff
20140326 21:07:43< iceiceice> idk what else could cause git push to give no output
20140326 21:08:01< Dugi> iceiceice: Here it is: http://pastebin.com/GGpkxJwr
20140326 21:08:04< RiftWalker> say you made a config object for each add-on, with the key as the add-on id.
20140326 21:08:16< thunderstruck> RiftWalker: What if you have unpublished add-on which has only empty _info.cfg?
20140326 21:08:31< iceiceice> yeah so the problem is that your fork remote doesn't have a .git ending
20140326 21:08:52< RiftWalker> hmm
20140326 21:09:07< iceiceice> if u go to the main page of your github fork
20140326 21:09:13< RiftWalker> say you made a check for it. if you find a _main, but not a _info, run the code to generate _info
20140326 21:09:16< iceiceice> theres a little textbox at the right
20140326 21:09:28< iceiceice> labeled "HTTPS clone URL"
20140326 21:09:47< thunderstruck> RiftWalker: Do you know what code generates _info.cfg?
20140326 21:09:51-!- Kexoth [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140326 21:09:54< iceiceice> this is mine: https://github.com/cbeck88/wesnoth-old.git
20140326 21:10:07< thunderstruck> And does generating it involves parsing whole add-on?
20140326 21:10:15< iceiceice> when you do "git remote -v" it should say something like that for both push and fetch
20140326 21:10:18< RiftWalker> thunderstruck: No, but I'm about to find out.
20140326 21:10:23-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140326 21:11:04< RiftWalker> thunderstruck: looks like addon/client.cpp
20140326 21:11:21< _8680_> Dugi: That was my fault then. I never use HTTPS URLs for remotes, so I gave you the wrong URL.
20140326 21:11:37-!- timotei_ [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 240 seconds]
20140326 21:12:52-!- timotei_ [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20140326 21:13:04< Dugi> Found that HTTPS clone URL, but how do I use it?
20140326 21:13:20< iceiceice> i think "git remote set-url "
20140326 21:13:21< RiftWalker> thunderstruck: It's currently part of install_addon, but it could be refactored.
20140326 21:13:33< _8680_> Dugi: `git remote set-url fork <new URL>`
20140326 21:14:36< _8680_> Well, I don’t *never* use HTTPS URLs. But I do usually use SSH “URLs”, which I find easier because they don’t require a username and password on each push.
20140326 21:14:41< Dugi> _8680_: Done it. What do I do next?
20140326 21:14:52< _8680_> Dugi: Now you should be able to push.
20140326 21:15:34< thunderstruck> RiftWalker: Let me be the devil's advocate once again. What about the stuff which is under data/?
20140326 21:15:48< thunderstruck> It does not have _info.cfg.
20140326 21:16:06< thunderstruck> data/multiplayer/ *
20140326 21:17:36< RiftWalker> Well, this would work specifically for add-ons. However, if we wrote up something to generate metadata (as a file, for persistance)  for any given config, it could be applied to anything.
20140326 21:19:33< RiftWalker> And it would be nice and modular. One place to make edits for parsing any kind of WML.
20140326 21:20:02< thunderstruck> RiftWalker: But how is it superior than current approach with defines?
20140326 21:20:04< Dugi> _8680_: I can't push, it tells me that I need to pull some changes first, but when I try to pull, it tells me that I would lose my edits and I should push first.
20140326 21:20:26< _8680_> Dugi: Please pastebin the output.
20140326 21:21:59< thunderstruck> RiftWalker: The idea with _info.cfg was that it was already there and so it would be convenient to use it, right?
20140326 21:22:04< Dugi> _8680_: Here: http://pastebin.com/bNjPnyjP
20140326 21:23:13< _8680_> You’re still on branch `master`?
20140326 21:23:23< _8680_> You didn’t run `git checkout -b […]`?
20140326 21:23:43< RiftWalker> Because it could be made to work across all content as-is, using only things that are necessarily present. And, in my opinion, it's a simpler approach.
20140326 21:23:52-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20140326 21:24:30< RiftWalker> Besides, the only things that wouldn't have _info.cfg are things that come with the game.
20140326 21:24:40< RiftWalker> All we have to do is generate that file once.
20140326 21:25:22< Dugi> _8680_: I am on branch master, because the cloned repository I have is tagged as master. What else should I do? What is supposed to be the [...] in `git checkout -b […]`?
20140326 21:25:49< RiftWalker> There is one problem i see, which is that changes in add-ons would have to be reflected in info
20140326 21:26:16< RiftWalker> But for dlc, I believe that would be re-generated on download.
20140326 21:26:20< _8680_> 2014-03-26  20:19:18  <_8680_> Since you haven’t committed yet, run `git checkout -b dugi/some-stuff` (change ‘some-stuff’ to whatever it is you’re working on). This will create a new topic branch, that you can then commit your changes onto. (A ‘topic branch’ is a branch made for one specific feature, issue, or such, rather than a ‘long-running branch’ like `master`.)
20140326 21:26:27< _8680_> 2014-03-26  20:20:15  <_8680_> To be clear, the commands don’t distinguish between long-running branches and topic branches — the distinction is only in how they’re used.
20140326 21:27:20< _8680_> Dugi: So you committed to `master`?
20140326 21:27:31< RiftWalker> Idk. Maybe Zaroth's approach was better: put your metadata in a define, rather than a file
20140326 21:28:41< thunderstruck> RiftWalker: I don't see why it's simpler approach. I actually think that it's much complex approach, because you have to tweak how add-ons are loaded and then take care of generating _info.cfg (this might have some drawbacks), while we already have code for defines.
20140326 21:28:52< Dugi> _8680_: Nope, nothing is comitted in the repo in browser.
20140326 21:29:15< _8680_> Dugi: Your fork on GitHub is not the same repository as your local repository.
20140326 21:29:24< thunderstruck> RiftWalker: Actually, metadata should be outside of a define.
20140326 21:29:37< _8680_> Dugi: Run `git log` to see what you have committed to your local repository.
20140326 21:30:44< Dugi> _8680_: git log says the same as before when I showed it to you.
20140326 21:31:36< _8680_> Dugi: Create a topic branch: `git checkout -b dugi/some-stuff master` (replacing ‘some-stuff’ as I said before). This command will create the new branch as a copy of `master`, and switch you to the new branch.
20140326 21:32:37< Dugi> _8680_: It reports that it already exists.
20140326 21:32:43< RiftWalker> Maybe I have defines and tags confused?
20140326 21:33:11< _8680_> Dugi: Okay. Does `git log dugi/some-stuff` show the same as `git log master`?
20140326 21:33:57< Dugi> _8680_: It tells the same.
20140326 21:34:10< _8680_> Dugi: `git branch --force master master~1` to forcibly reset your `master` branch to point to the commit before your last commit to it.
20140326 21:34:38< Dugi> _8680_: Okay, what should I do now?
20140326 21:34:54< _8680_> Dugi: `git push fork dugi/some-stuff`
20140326 21:35:50-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140326 21:36:32-!- timotei_ [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 268 seconds]
20140326 21:36:38< Dugi> _8680_: Done. And it is uploaded.
20140326 21:36:51-!- timotei_ [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20140326 21:37:57< _8680_> Dugi: Okay. Now, to file a pull request on GitHub, go to <https://github.com/Dugy/wesnoth>. You should see a green box saying that you recently pushed and asking whether you want to file a pull request. Click the pull request button.
20140326 21:38:59< Dugi> _8680_: It uploaded only the new files, not the changes I have done to existing files.
20140326 21:39:31< Dugi> _8680_: The changes still exist on my computer, but no in the online repository.
20140326 21:39:51< thunderstruck> RiftWalker: Did you check how _info.cfg is actually generated? E.g. is it needed to parse whole add-on or not?
20140326 21:39:57< _8680_> Dugi: Did you not `git add` those files?
20140326 21:40:49< Dugi> _8680_: I git added only the new files I created, I thought that when git diff can see what I changed in the existing files, it will also be committed.
20140326 21:41:11< lipkab> git commit -a and it's all fine.
20140326 21:41:17< lipkab> Who needs git add.
20140326 21:41:56< _8680_> Dugi: Okay, `git add` those files, then `git commit -v --amend` to add them to the commit.
20140326 21:42:22< elias> i usually use "git add -p" to be sure nothing wrong gets committed
20140326 21:42:28< _8680_> lipkab: `git commit -a` is bad practice because it can result in accidentally committing things.
20140326 21:43:04< iceiceice> dugi: i highly recommedn this website if you want a guide to the basic git commands http://gitref.org/
20140326 21:43:09< RiftWalker> thunderstruck: When it's generated, the whole config is already loaded because it was just downloaded.
20140326 21:43:11< Dugi> I carefully read what it committed, it seems to be okay.
20140326 21:43:26< Dugi> I'll just issue a pull request now?
20140326 21:43:33< RiftWalker> thunderstruck: So as it is now, yes.
20140326 21:43:45< lipkab> git add is bad practice because it can accidentally result in not committing things.
20140326 21:43:47< _8680_> `git add -p` is also good for that reason, or if you’ve made some changes to a file and want some of the changes to be in one commit and some in another commit.
20140326 21:44:20< RiftWalker> thunderstruck: So do you think it would be easier for each add-on to have its own define= the way campaigns do?
20140326 21:44:21< _8680_> lipkab: Accidentally not committing things is better than accidentally committing things, because it’s easier to fix.
20140326 21:44:24< gfgtdf> how can git add result in not committing things ?
20140326 21:44:51< _8680_> gfgtdf: If one doesn’t `git add` all the things one wants to commit.
20140326 21:45:15< thunderstruck> RiftWalker: Yeah. I think it's easier approach. And it's also approach which is currently being used. That means you don't reinvent a wheel.
20140326 21:45:26< gfgtdf> _8680_: you suggest always using git all ??
20140326 21:45:29< thunderstruck> But that's all subject to my personal opinion, though :)
20140326 21:45:41< gfgtdf> add*
20140326 21:45:53< iceiceice> fwiw i prefer to use git add separately from git commit
20140326 21:45:57< _8680_> gfgtdf: Yes, or `git commit <files...>`.
20140326 21:46:22< RiftWalker> thunderstruck: what if an add-on doesn't use whatever tag we create to implement it?
20140326 21:47:00< gfgtdf> how is the it less likeley to firget  files when you use commit <files> tna when you use git add <files>?
20140326 21:47:08< gfgtdf> s/the/it
20140326 21:47:11< RiftWalker> Then it would work as it does now, i suppose.
20140326 21:47:16< thunderstruck> RiftWalker: For the sake of compatability, we could keep supporting MULTIPLAYER define as it is now.
20140326 21:47:29< thunderstruck> RiftWalker: I don't really see problems with that just now.
20140326 21:47:43< iceiceice> if you forget something you can just squash things together later when you rebase
20140326 21:48:02-!- timotei_ [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 265 seconds]
20140326 21:48:32< _8680_> Dugi: You’ll now need to overwrite the version of the commit that’s in your fork with the version that’s in your local repository. This is done by `git push --force fork dugi/addon_reviews`. Note that `git push --force` (or `-f`) is a potentially dangerous operation, and should not be used on branches other than your personal topic branches without deliberation.
20140326 21:48:33-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20140326 21:48:38-!- timotei_ [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20140326 21:49:04< _8680_> gfgtdf: It’s not, it’s just an alternative that’s less flexible but a bit shorter to type.
20140326 21:49:23< thunderstruck> RiftWalker: BTW, if you're referring to Zaroth's proposal, keep in mind that config loading now is much more modular.
20140326 21:49:32< RiftWalker> thunderstruck: I got sp campaigns loading through the mp interface. It was one line of code. That's probably not what we want in the long run, but it does work. I think sp could basically do that, but automatically set a lot of the variables.
20140326 21:49:55< thunderstruck> RiftWalker: So, his proposed approach (if one even exists - I don't remember that) might be different.
20140326 21:50:05< _8680_> I do often use `git commit -a` myself, but only when I fully know what I’m doing, and I always review the changes to be committed before *and* after committing.
20140326 21:50:29< thunderstruck> RiftWalker: I guess you changed the place where mp::create checks for type=?
20140326 21:50:29< RiftWalker> thunderstruck: Still, I think his idea to have a single tag with the functionality of [campaign], [multiplayer], and [scenario] was basically on the right track.
20140326 21:51:14< iceiceice> RiftWalker: how can you merge campaign and scenario though?
20140326 21:51:41< Dugi> _8680_: The entire folder looks okay, issuing a pull request.
20140326 21:51:41< _8680_> (Specifically, I always use `git commit -v` to see the changes to be committed while writing my commit message. In my opinion, one should never use `-a` without `-v`.)
20140326 21:51:59< gfgtdf> iceiceice: what happends when i type 'git rebase -i ' without andfurthe arguments ?
20140326 21:52:11< iceiceice> probly an error idk
20140326 21:52:38< RiftWalker> thunderstruck: I forget the exact file, but yes.
20140326 21:52:49< iceiceice> chris@chris-KLR650 ~/wesnoth-src/clone/wesnoth-old $ git rebase -i
20140326 21:52:50< iceiceice> There is no tracking information for the current branch.
20140326 21:52:50< iceiceice> Please specify which branch you want to rebase against.
20140326 21:52:50< iceiceice> See git-rebase(1) for details
20140326 21:52:57-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Ciao]
20140326 21:53:02-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20140326 21:54:06< Dugi> Pull request issued.
20140326 21:54:37< RiftWalker> thunderstruck: it was in create_engine::init_all_levels()
20140326 21:54:45< thunderstruck> RiftWalker: Well, it was still an idea of using defines. And where exactly you put that metadata is just a matter of preference.
20140326 21:54:46< RiftWalker> iceiceice: good question. let me see
20140326 21:55:32< RiftWalker> iceiceice: His idea was to treat scenarios as 1-scenario campaigns.
20140326 21:55:59< iceiceice> i see
20140326 21:56:11< gfgtdf> Dugi: private member variable like started_at should end with an underscore
20140326 21:56:29< iceiceice> y that's a convention...
20140326 21:56:37< iceiceice> ok what are the other things you are supposed to do on first commit...
20140326 21:56:48< iceiceice> *first pull request
20140326 21:57:06< Dugi> gfgtdf: In some files, it ends with an underscores, in others, it doesn't, so I could not say what was the tradition in wesnoth.
20140326 21:57:11-!- trademark [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has joined #wesnoth-dev
20140326 21:57:26< iceiceice> 1. make a changelog entry
20140326 21:57:37< lipkab> Dugi: Where are the files it doesn't?
20140326 21:57:37< iceiceice> 2. make a players_changelog entry since the players would notice this
20140326 21:57:45< lipkab> *where it
20140326 21:57:57< iceiceice> 3. add yourself to data/core/about.cfg under "Miscellaneous Contributors"
20140326 21:58:05< thunderstruck> RiftWalker: Actually, there are some problems with multiplayer scenarios and defines.
20140326 21:58:20< Dugi> lipkab: It was somewhere in the src/addons folder, if I remember correctly.
20140326 21:58:28< thunderstruck> RiftWalker: mp::create window wants to show the minimap for each of them.
20140326 21:59:03< thunderstruck> RiftWalker: So, wrapping map data with define is a problem.
20140326 21:59:37-!- noy [~Noy@24.244.23.133] has joined #wesnoth-dev
20140326 21:59:40-!- noy [~Noy@24.244.23.133] has quit [Changing host]
20140326 21:59:40-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140326 22:00:07< lipkab> Dugi: Those are public data members there. Private data members do end with _ by convention.
20140326 22:00:35< RiftWalker> thunderstruck: I see. Couldn't you require an image as [campaign] does?
20140326 22:00:55< RiftWalker> or rather allow for one?
20140326 22:01:22< thunderstruck> RiftWalker: You could require it, but generally people would prefer to see a minimap for scenarios.
20140326 22:01:59< Dugi> lipkab: Haven't noticed that. I'll try to keep that convention next time. If there will be a next time.
20140326 22:02:00< lipkab> Dugi: You're very kind to grant the copyright of your new files to shadowm, but in reality you should put your own name there :)
20140326 22:02:48< Dugi> lipkab: Oops, copyright was hidden by my IDE, I haven't noticed that properly.
20140326 22:02:58< RiftWalker> thunderstruck: I don't think it'll hurt too much to leave mp scenarios as-is, if everything else is being isolated. Besides, it's not a whole lot of data to load.
20140326 22:03:23< thunderstruck> RiftWalker: It might be. Some users will have loads of MP scenarios downloaded.
20140326 22:04:00-!- ykanarev [~ykanarev@78.81.70.234] has quit [Quit: Leaving]
20140326 22:04:44< RiftWalker> thunderstruck: couldn't you just put map info under #ifdef multiplayer?
20140326 22:04:59< lipkab> Dugi: There's no definition for taddon_reviews_list::reviews_liked.
20140326 22:06:04< Dugi> lipkab: Are you sure? Because I could compile it. Maybe I forgot to include some files, damn.
20140326 22:06:06< thunderstruck> RiftWalker: You could. Although that would require special for care later on, because map would no longer be under [multiplayer] tag.
20140326 22:06:14< lipkab> Dugi: At a couple instances you pass string arguments by value instead of reference.
20140326 22:06:36< lipkab> Dugi: A missing definition doesn't prevent compiling.
20140326 22:06:46< Dugi> lipkab: That's possible.
20140326 22:07:01< iceiceice> Dugi, I'm surprised you went with Dugy over Dug1 :p
20140326 22:07:17< lipkab> It will cause a linking error, but only if you attempt to call the function.
20140326 22:08:15< Dugi> iceiceice: Dugi was taken. Dugy is usually used by my brother.
20140326 22:08:45< Dugi> lipkab: It's probably a leftovers of something, then.
20140326 22:09:42< RiftWalker> thunderstruck: Yeah, I see that... Any ideas?
20140326 22:12:08-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 240 seconds]
20140326 22:12:30< RiftWalker> thunderstruck: Actually, I don't see why you couldn't keep it in the [multiplayer] tag, outside of your content #ifdef
20140326 22:13:14< thunderstruck> RiftWalker: Yeah, you could with additional define
20140326 22:14:11< thunderstruck> RiftWalker: But that breaks the idea of a single metadata tag for campaigns and scenarios
20140326 22:14:41< thunderstruck> RiftWalker: Wait..
20140326 22:14:52< gfgtdf> 	thunderstruck: you are plannignt o have a metadata tag for mp just liek for sp ?
20140326 22:14:56< gfgtdf> planning
20140326 22:15:31< thunderstruck> gfgtdf: Currently, this is just a discussion about possible options.
20140326 22:15:50< gfgtdf> hm ok
20140326 22:15:54< thunderstruck> RiftWalker: can you have an attribute without a top-level tag?
20140326 22:16:15< gfgtdf> you mean attributes outdie any tag ?
20140326 22:16:19< gfgtdf> outside
20140326 22:16:26< thunderstruck> yeah
20140326 22:16:27< lipkab> Dugi: request_addons_list's signature and doc comment are kinda out of sync.
20140326 22:16:48< lipkab> Same for rate_addon.
20140326 22:17:04< lipkab> ...and upload_gameplay_times.
20140326 22:17:28< gfgtdf> thunderstruck: i tihnk not.
20140326 22:17:45< gfgtdf> why dont you just put mapdata={<mapfile>} in teh metagag
20140326 22:17:47< Dugi> lipkab: I am not perfectly sure what are the conventions around this documentation, so it's possible that I wrote something wrong.
20140326 22:18:00< gfgtdf> aswell as in teh scenario/multiplayer tag ?
20140326 22:18:32< thunderstruck> gfgtdf: Wouldn't that require to parse a map twice?
20140326 22:18:43< lipkab> Dugi: @param p refers to the argument 'p' of the following function.
20140326 22:18:45< thunderstruck> (I really don't know)
20140326 22:19:02< lipkab> So you'd naturally expect the method to have such an argument.
20140326 22:19:02< gfgtdf> 	thunderstruck: well the non mukltiplayer tag isnt pardes becasue it's inside a diabled if 
20140326 22:19:14< gfgtdf> s/non/
20140326 22:19:34< Dugi> lipkab: Should I correct it and make another pull request, or you'll correct it?
20140326 22:20:02< thunderstruck> gfgtdf: But it would be unnecesarry parsed the next time.
20140326 22:20:10< thunderstruck> gfgtdf: Although that's a small thing..
20140326 22:20:22< lipkab> Dugi: You can update your pull request with additional commits, and you'll need to fix other things as well anyways.
20140326 22:20:22< thunderstruck> Since it would be needed for only one scenario this time.
20140326 22:21:11< RiftWalker> thunderstruck: Would this outline work?
20140326 22:21:13< RiftWalker> http://pastebin.com/cva5V84q
20140326 22:21:14< shadowm> "Added a system to allow players to choose an add-on better." <-- This isn't a good commit subject.
20140326 22:21:16-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140326 22:21:44< shadowm> It's not too different from commits titled "Fix a bug".
20140326 22:21:50< RiftWalker> thunderstruck: or even adding an #ifdef multiplayer guard aroudn map
20140326 22:22:00< RiftWalker> /s/dn/nd
20140326 22:22:33< shadowm> The algorithm for ratings is alluded to in the commit description but that's it. It's not explained at all.
20140326 22:22:36< iceiceice> shadowm: i will title all future commits "make wesnoth better"
20140326 22:22:50< thunderstruck> RiftWalker: Yeah it should work. Although gfgtdf approach seems to be a bit more elegant.
20140326 22:23:04< lipkab> shadowm: At Apertium, the most common commit message is "more".
20140326 22:23:09< lipkab> :P
20140326 22:23:15< iceiceice> haha
20140326 22:23:22< _8680_> How terrible.
20140326 22:23:30< Dugi> lipkab: I'll just log this discussion and fix and upload the things tomorrow.
20140326 22:23:33< shadowm> Dugi: If you are going to use a different widget naming scheme than the standard you could at least be consistent in the same dialog.
20140326 22:23:59< Dugi> shadowm: In which file?
20140326 22:24:00< thunderstruck> thunderstruck: Because it allows you to separate metadata from actual data. And the only tradeoff is that you need map= twice.
20140326 22:24:05< shadowm> The documentation lists 'lblTitle' and 'rating_input' for gui2/taddon_rate.
20140326 22:24:17< shadowm> *other than
20140326 22:24:27< lipkab> Dugi: Okay. Wesbot logs the whole channel for your convenience, by the way.
20140326 22:25:07< Dugi> lipkab: Done proofreading?
20140326 22:25:14< Dugi> shadowm: Ah, that. I'll fix that.
20140326 22:25:20< lipkab> Dugi: typedef struct blah { } blah; is a really unique syntax for creating structs :)
20140326 22:25:26< lipkab> Dugi: Almost.
20140326 22:25:42< shadowm> Dugi: Opening braces should go below the function declaration, not on the same line (re gui/dialogs/addon/reviews_list.cpp:64).
20140326 22:25:50< Dugi> lipkab: What should I use instead of typedef struct blah { } blah.
20140326 22:26:00< lipkab> struct blah {};
20140326 22:26:15< shadowm> lipkab: It's not unique, it's Cish.
20140326 22:26:31< Dugi> lipkab: That's impractical to use without typedef, no?
20140326 22:26:33< lipkab> Cish is typedef struct {} blah;
20140326 22:26:41< RiftWalker> thunderstruck: I'm not seeing how it differs
20140326 22:26:51< lipkab> Dugi: No.
20140326 22:27:06-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 268 seconds]
20140326 22:27:09< _8680_> Dugi: In C++, one can refer to it as ‘blah’, rather than ‘struct blah’.
20140326 22:27:28< Dugi> _8680_: I didn't know that.
20140326 22:27:29-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 252 seconds]
20140326 22:28:12< lipkab> Dugi_: Why did you make manager_ui::addons_ a reference?
20140326 22:28:25< lipkab> That could be... dangerous.
20140326 22:28:25< shadowm> Dugi: Could you explain in plain words what it is that gui2::taddon_reviews_list::cut_into_more_lines() does?
20140326 22:28:38< shadowm> (Hint: there's a problem with it.)
20140326 22:29:00< Dugi> It is supposed to divide the review into more lines, because the GUI doesn't do that automatically.
20140326 22:29:24< shadowm> But could you explain what you *believe* is done with the parameters and the return value?
20140326 22:29:30< thunderstruck> RiftWalker: Having metadata outside of actual scenario tag you could have a one MetadataWML thing for campaigns and scenarios.
20140326 22:29:45< lipkab> Dugi: Wrong indentation at manager_ui:350-351.
20140326 22:30:25< lipkab> And 793-794.
20140326 22:30:28< thunderstruck> RiftWalker: I also remembered that number of sides for MP scenarios is calculated by actually looking at [side] tags.
20140326 22:30:36< thunderstruck> RiftWalker: So this is also a bit of a problem.
20140326 22:31:20< Dugi> lipkab: I think that I wanted the reviews' rating to add some notes to it, but I later decided not to do that. So there is no actual reason why is it a reference.
20140326 22:32:31< Dugi> shadowm: Is it destroyed at some awkward time?
20140326 22:32:51< shadowm> Dugi: I asked you a specific question.
20140326 22:33:24< RiftWalker> thunderstruck: Why not merge [campaign] with [scenario], including metadata in that one tag
20140326 22:33:42< thunderstruck> RiftWalker: merge?
20140326 22:34:39< Dugi> shadowm: I don't know what was it supposed to do, I see that the inserted parameter and the return function are done quite in a silly way.
20140326 22:34:55< shadowm> Dugi: Did you not write it?
20140326 22:35:12< RiftWalker> thunderstruck: Nevermind, it would be pretty wonky. It's basically what zaroth planned though.
20140326 22:35:20-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140326 22:35:26< Dugi> shadowm: I wrote it, but I was very sleepy that day.
20140326 22:36:39< lipkab> Dugi: You might want to make taddon_rate's ctor private.
20140326 22:36:46< shadowm> Dugi: `inserted` is passed by value, then you create a superfluous local read-write reference to it and return a read-write reference to the variable pointed to by that superfluous read-write reference, i.e. `inserted`.
20140326 22:37:12< Dugi> shadowm: I see that now.
20140326 22:37:15< RiftWalker> thunderstruck: It seems for number of players you'd also have to include that in your metadata, and load it twice
20140326 22:37:19< shadowm> `inserted` is a temporary.
20140326 22:37:42< RiftWalker> thunderstruck: it would just have to be defined explicitly, I suppose.
20140326 22:37:56< thunderstruck> RiftWalker: but the problem is that we're loosing a way to automatically detect number of sides.
20140326 22:38:02< shadowm> Keeping a non-const reference to a temporary past its scope leads to all kinds of problems.
20140326 22:38:19< Dugi> lipkab: Yeah, it might make sense to be private.
20140326 22:38:33< thunderstruck> RiftWalker: Although it's probably not a huge thing.
20140326 22:38:59< thunderstruck> RiftWalker: Sides are already need to be defined explicitly for MP Campaigns.
20140326 22:39:19< Dugi> shadowm: I normally avoid that, but that monday, I was really bad, but I needed to do something offline while overlooking a mostly automated experiment.
20140326 22:39:40< shadowm> Dugi: There is a random useless empty line addition near the top of src/addon/client.cpp.
20140326 22:40:19< Dugi> shadowm: How did you even notice that?
20140326 22:40:33< shadowm> Dugi: Reading the diff.
20140326 22:40:37< shadowm> https://github.com/Dugy/wesnoth/commit/ddc1b6a73e8192fe8694c602a34d33d4b38b8731#diff-ad698b47a1105fcb28770f86772638faR31
20140326 22:40:48< RiftWalker> thunderstruck: True. I mean, you could always split your #ifdef blocks around any data that you want to load: map, sides, etc.
20140326 22:40:54< Dugi> shadowm: Ah, yes.
20140326 22:40:54< shadowm> You might want to get into the habit of reading your own diffs too.
20140326 22:41:19< thunderstruck> RiftWalker: Yeah, but if you do that around map and sides, then there's basically no need to have ifdefs at all.
20140326 22:41:34< lipkab> Dugi: taddon_description::current_users_rating should be private.
20140326 22:41:55< shadowm> Dugi: *Always* use scoped blocks instead of single statements for control block bodies in new code. Case in point: https://github.com/Dugy/wesnoth/commit/ddc1b6a73e8192fe8694c602a34d33d4b38b8731#diff-ad698b47a1105fcb28770f86772638faR296
20140326 22:42:03< thunderstruck> RiftWalker: Do you have any questions?
20140326 22:42:07< thunderstruck> I'll be going soon.
20140326 22:42:41< RiftWalker> thunderstruck: I think I'm good for now. Thanks for your time.
20140326 22:42:56-!- gfgtdf_ [~chatzilla@d226137.adsl.hansenet.de] has joined #wesnoth-dev
20140326 22:43:05< shadowm> Dugi: We also have algorithms to iterate over generic containers so you don't need to do things like for(size_t n = 0; container.size(); ++n) { stuff(); } unless you really need the indexing.
20140326 22:43:19< RiftWalker> I'm also off for now. I'll be back in 30.
20140326 22:43:41< thunderstruck> RiftWalker: No problem. Bye.
20140326 22:43:43-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Quit: leaving]
20140326 22:43:47< shadowm> Or unless you absolutely need to optimize extremely performance-sensitive code (if you don't know for sure, it means you don't).
20140326 22:44:13< Dugi> shadowm: What is a scoped block? And where did I use the usual iteration instead of the proper one?
20140326 22:44:28< lipkab> Dugi: taddon_reviews_list::taddon_reviews_list's doc comment is stub.
20140326 22:44:59-!- gfgtdf [~chatzilla@f054146168.adsl.alicedsl.de] has quit [Ping timeout: 268 seconds]
20140326 22:45:05-!- gfgtdf_ is now known as gfgtdf
20140326 22:45:10< shadowm> Dugi: if(...) { stuff(); } versus if(...) stuff();
20140326 22:45:52< shadowm> Using full blocks has added benefits in certain cases and generally improves readability and decreases the room for obvious catastrophic mistakes.
20140326 22:46:11< shadowm> IIRC somebody at Apple learned that lesson recently.
20140326 22:46:25< Dugi> shadowm: Are there some exceptions? Sometimes it looks more readable if more ifs are inlined. Not telling that this was the case.
20140326 22:47:00< shadowm> Dugi: Oh, and for generic containers from the STL, always use empty() instead of comparing the return value of size() with 0.
20140326 22:47:19< Dugi> shadowm: Where did I do that?
20140326 22:47:41-!- RiftWalker [~RiftWalke@129.59.115.25] has quit [Ping timeout: 245 seconds]
20140326 22:48:01< shadowm> Dugi: https://github.com/Dugy/wesnoth/commit/ddc1b6a73e8192fe8694c602a34d33d4b38b8731#diff-ad698b47a1105fcb28770f86772638faR296
20140326 22:48:46< shadowm> Those are apparently std::string objects, so there shouldn't be much of a complexity difference between empty() and size() == 0. However, you should still prefer empty() to build the habit.
20140326 22:49:15< lipkab> Dugi: If I understand correctly, slider::decimal is used to display labels like 9/10 next to the slider?
20140326 22:49:16< shadowm> Why it matters? Imagine your container is implemented as a linked list (std::list).
20140326 22:49:45< shadowm> Checking whether it's empty is a O(1) operation. Checking how many items it has is a O(n) operation.
20140326 22:50:31< Dugi> shadowm: Corrected that.
20140326 22:50:55< Dugi> lipkab: Yes. I needed to add a few extra settings to the slider.
20140326 22:50:58< shadowm> That means that in such case, to get the number of items you have to iterate over every element of the list to find the next one and increase a counter.
20140326 22:51:49< shadowm> For containers like std::basic_string and std::vector there's a separate static counter I believe, so the operation should be as cheap as checking whether the container is empty.
20140326 22:52:12< lipkab> Dugi: What's the point of restricting the divident to [0;10]?
20140326 22:52:14< shadowm> But from a semantic standpoint, if(foo.empty()) is far more natural than if(foo.size() == 0).
20140326 22:52:38< lipkab> (Especially that zero divident is nonsense! :P)
20140326 22:52:44< Dugi> shadowm: Yes, that makes sense. I'll stick to that.
20140326 22:53:37< Dugi> lipkab: Because I saw more than 10^10 possible values as obvious nonsense.
20140326 22:54:19< Dugi> lipkab: Zero dividient is impossible, if set to 0 it would be normal, 10^0.
20140326 22:54:52< lipkab> Dugi: I don't really understand, you've just stated that it's a divisor.
20140326 22:55:01< shadowm> Dugi: The Doxygen comment block addition in addon/client.hpp:65 is pointless and also bad form (the full description for that symbol should go before the first @param). https://github.com/Dugy/wesnoth/commit/ddc1b6a73e8192fe8694c602a34d33d4b38b8731#diff-67079b1ede34d3f523df21930cbd7c8eR65
20140326 22:55:24< shadowm> It also doesn't make sense.
20140326 22:55:45< shadowm> request_addons_list() must have no permanent side-effects on the server.
20140326 22:56:09< lipkab> Dugi: Oh, okay it can display only x/10^n style strings.
20140326 22:56:48< shadowm> https://github.com/Dugy/wesnoth/commit/ddc1b6a73e8192fe8694c602a34d33d4b38b8731#diff-29563a6c2324dd8b8d477c475b36127eR83 <- you are instantiating a float from a double.
20140326 22:56:57< lipkab> Well, let me rephrase my question: what's the point of restricting the divisor to 10^n?
20140326 22:57:36< shadowm> Okay, this is the point at which I believe this massive commit really needs to be broken down into smaller logical units.
20140326 22:57:47< Dugi> shadowm: Why? The gameplay times should be uploaded when logging in to the add-on server, and that is done always at the same time as the list of add-ons is requested.
20140326 22:58:10< Dugi> lipkab: I just didn't want weird decimals to appear there.
20140326 22:58:18< shadowm> There seems to be more functionality included in it than just adding review support.
20140326 22:58:46< shadowm> And I would greatly prefer if the backend changes were done separately from the frontend changes. That is how I've managed this code thus far.
20140326 22:58:53< lipkab> Dugi: Uh, like 4/5? What's the problem with that?
20140326 23:00:00< shadowm> Dugi: The addons_client class is designed for flexibility for users of the class. I may decide to request the list of add-ons without wanting to do anything else.
20140326 23:00:03< Dugi> shadowm: What I am supposed to do then? I have all the changes done, and I don't know how would I split them. And most of them work together, maybe except the gameplay times.
20140326 23:00:31< shadowm> Each method should preferably issue exactly one request, too.
20140326 23:01:03< Dugi> shadowm: That would be quite a lot of requests, that would not work separately.
20140326 23:01:24< shadowm> I haven't made it very far through this mess, but I'd expect there are two separate requests to the add-ons server to upload that stuff and to request the add-ons list.
20140326 23:02:04< shadowm> Right?
20140326 23:02:23< Dugi> shadowm: I didn't understand the question, it makes more sense after reading the second one.
20140326 23:03:21< Dugi> shadowm: I thought it quite a waste to send two requests always in a row. More efficency for losing a bit of versatility. Maybe an argument could be added to that method if it should also upload the statistics.
20140326 23:03:42< shadowm> Dugi: We don't need to go overboard with efficiency here.
20140326 23:04:03< shadowm> The server-side versatility is currently necessary for operations with the external wesnoth_addon_manager client.
20140326 23:04:16< lipkab> Dugi: Apologies. I really should've read the whole line before commenting :P
20140326 23:04:29< shadowm> The client-side versatility will be needed once people get around to making it possible to auto-download required add-ons from the MP lobby, etc.
20140326 23:04:30< lipkab> I figured it out at last.
20140326 23:04:31< gfgtdf> i think we should allow the user to disable the collection of this data.
20140326 23:04:42< shadowm> Also what gfgtdf said.
20140326 23:05:02< lipkab> shadowm: How do you do bold text?
20140326 23:05:18< shadowm> lipkab: Pango or legacy GUI1 markup?
20140326 23:05:25< Dugi> shadowm: So I should split it or just add a bool argument if it should be uploaded or not?
20140326 23:05:30< lipkab> shadowm: IRC.
20140326 23:05:36< shadowm> Dugi: Split it.
20140326 23:05:57< shadowm> lipkab: \002. The exact way to enter that varies from client to client.
20140326 23:06:10< lipkab> \002 blablah
20140326 23:06:12< lipkab> :(
20140326 23:06:14-!- RiftWalker [~RiftWalke@129.59.115.25] has joined #wesnoth-dev
20140326 23:06:40< shadowm> No, I mean literally the character \002.
20140326 23:06:48< lipkab> Oh.
20140326 23:07:07< lipkab> %B blablah
20140326 23:07:13< lipkab> Mm.
20140326 23:07:35-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20140326 23:07:44< lipkab> %B blablah %B
20140326 23:07:47< shadowm> Dugi: And the same goes for the overall commit -- frontend/backend changes separation would be a good first step.
20140326 23:07:51-!- Spoffy [~chatzilla@152.78.175.8] has quit [Read error: Operation timed out]
20140326 23:08:28< shadowm> Some actual description of the rating algorithm alluded to in the first commit's description would also be good.
20140326 23:08:39< lipkab> blahblah
20140326 23:08:46< lipkab> Yippie!
20140326 23:08:57< janebot> Wesnoth Forums | Developers’ Discussions • Re: Suggestion: keep backwards compatibility by jb [ 03-26-2014 23:08 ] [ http://r.wesnoth.org/p568660 ]
20140326 23:09:06< iceiceice> horray
20140326 23:09:08< shadowm> A second step would be to decide how tied together are the addition of add-on reviews, add-on playtime stats, and add-on ratings.
20140326 23:09:22-!- Spoffy [~chatzilla@152.78.175.8] has joined #wesnoth-dev
20140326 23:09:35< shadowm> I'd greatly prefer if they were separate enough so those could become the basis of three separate commit sub-sets.
20140326 23:09:38< Dugi> shadowm: Still not getting why should it be separated, when one doesn't work without the other.
20140326 23:09:53< iceiceice> Dugi: how did you test this
20140326 23:09:57< shadowm> Because it makes reviewing this code and making a choice as to whether to merge it or not easier.
20140326 23:10:02< iceiceice> presumably you built pieces one at a time and tested them right?
20140326 23:10:05< iceiceice> so use that order for the commits
20140326 23:10:23< Dugi> shadowm: The play times could be separated, but reviews and ratings use same structs.
20140326 23:10:42< Dugi> But I don't have all the subversions.
20140326 23:10:48< lipkab> Dugi: You're using variables, constants, non-const references and const references as loop variables in BOOST_FOREACH statements.
20140326 23:10:51< Dugi> I was testing the parts using various logs etc.
20140326 23:11:07-!- Spoffy [~chatzilla@152.78.175.8] has quit [Read error: Operation timed out]
20140326 23:11:18< shadowm> Dugi: I'm not talking of language technicalities like that. I don't care whether they use the same structs or use a long series of static variables.
20140326 23:11:22< Dugi> lipkab: Not getting why is it a problem, in what context is it?
20140326 23:11:39< shadowm> Dugi: What I'm talking about is the actual concepts behind the commit.
20140326 23:11:57< shadowm> One commit obviously has to pave the way for the others.
20140326 23:12:03< iceiceice> see if you can recreate the process in your head and recommit it that way
20140326 23:12:10< iceiceice> because think of it this way
20140326 23:12:16< iceiceice> suppose that we test it and someone finds they get a segfault
20140326 23:12:23< lipkab> Dugi: It results in excessive copying of objects.
20140326 23:12:29< iceiceice> (maybe because you had a reference to a temporary variable on the stack :p)
20140326 23:12:37< shadowm> So that commit would create the necessary data structures for itself and the second commit would then build further upon the first by extending those structures.
20140326 23:12:37< Dugi> lipkab: Where did I do that?
20140326 23:12:39< iceiceice> if the commits are broken up the person can test each version
20140326 23:12:47< iceiceice> and say "its in these 10-20 lines"
20140326 23:12:57< iceiceice> instead of "its somewhere in a haystack of 1000 lines"
20140326 23:13:02< iceiceice> the latter is not really maintainable
20140326 23:13:51< Dugi> But doing that would be really annoying right now, when I have it all almost finished. Deleting most of the stuff, debugging it, then getting back again, debugging it to make another commit... endless.
20140326 23:14:04< shadowm> If I had a readable commit set I would also be able to provide better critique for the actual concepts being implemented here. Right now all I see is a wall of code.
20140326 23:14:11< lipkab> Dugi: playsingle_controller.cpp and info.cpp.
20140326 23:14:58< lipkab> Oops, it's already tomorrow here.
20140326 23:15:01< lipkab> Bye all.
20140326 23:15:02-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Quit: Vannak idők, mikor menni kell]
20140326 23:15:52< shadowm> gui2::tslider: void set_decimals(int decimals_set)  <- Huh?
20140326 23:16:36< Dugi> Uh, it's quite late for me too.
20140326 23:16:44< shadowm> Why are the underlying private fields (which also lack the private/protected field trailing underscore) documented here instead of the accessor methods?
20140326 23:17:19< shadowm> Also, I'd prefer if that part became a separate PR for mordante.
20140326 23:17:31< iceiceice> Dugi: you've got whitespace issues also
20140326 23:17:33< shadowm> Being a GUI2 framework change and all.
20140326 23:17:42< iceiceice> in src/addon/manager_ui.cpp
20140326 23:18:21< shadowm> +    addon_info::this_users_rating current_users_rating;
20140326 23:18:36< Dugi> shadowm: What's wrong withat getter?
20140326 23:18:43< Dugi> iceiceice: I have corrected that already.
20140326 23:18:43< shadowm> Neither the type name nor the variable name are optimal.
20140326 23:18:57< Dugi> shadowm: Ah, that. I'll fix that.
20140326 23:18:58< shadowm> Dugi: It's not a getter, also see what I said immediately afterwards.
20140326 23:20:14< Dugi> shadowm: I'll rename them, then.
20140326 23:20:22< shadowm> Why can't the type name be addon_info::rating and the variable name current_rating (or alternatively addon_info::rating_value and rating)? What alternative there is in the code to the rating being done by users?
20140326 23:20:53< shadowm> Or what alternative there is in the code to the type describing a rating done by "this user"? (As opposed to everyone else?)
20140326 23:21:34-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20140326 23:21:40< shadowm> (Hm, alternatively? addon_info::foo_value and addon_info::foo actually sounds much better in my mind, now that I think about it.)
20140326 23:22:48< shadowm> Okay, what's the justification for addons_list being arbitrarily renamed to list_of_addons in gui2/taddon_description?
20140326 23:23:33< shadowm> Oh, it's not being renamed, you are referring to a newly introduced class field.
20140326 23:24:04< Dugi> In that case, I should also name it addons_list and addons_list_ instead.
20140326 23:24:07< shadowm> And there are a bunch of leading underscores being thrown about, when symbols with a leading underscore are by convention reserved for platform libraries (e.g. libc).
20140326 23:24:50-!- pyromancer2 [~pyromance@130.68.239.68] has joined #wesnoth-dev
20140326 23:24:54< Dugi> Where are these leading underscores thrown about?
20140326 23:24:55-!- pyromancer2 [~pyromance@130.68.239.68] has quit [Client Quit]
20140326 23:25:04< shadowm> https://github.com/Dugy/wesnoth/commit/ddc1b6a73e8192fe8694c602a34d33d4b38b8731#diff-bc30099d5b938e642d30fba32f000a40R314
20140326 23:26:00< shadowm> Okay, I'm tired and hungry, so I'll stop here before my head breaks from all the code.
20140326 23:26:17< shadowm> What these commits really lack is proper VCS discipline.
20140326 23:26:38< shadowm> Changes done in a gradual fashion in logical units, like when you build a house.
20140326 23:26:51< iceiceice> bbl
20140326 23:27:10< happygrue> bbq?  Better keep it from shadowm, he's hungry
20140326 23:27:35< iceiceice> me too :) now i want some bbq
20140326 23:27:38< Dugi> shadowm: I'll try to obey that committing discipline next time.
20140326 23:27:41< happygrue> mmm
20140326 23:27:45-!- iceiceice [~chris@207-237-132-90.ny.subnet.cable.rcn.com] has quit [Quit: Leaving]
20140326 23:28:50< shadowm> `git log --stat src/addon src/gui/dialogs/addon*` will reveal more or less how I deal with add-ons manager code myself (use -p instead of --stat for actual diffs).
20140326 23:29:49< Dugi> I will try to do that next time.
20140326 23:29:56< shadowm> No, not next time, this time.
20140326 23:30:39< shadowm> Anyway, that's just a research idea. Common sense is always the overruling directive.
20140326 23:31:17< shadowm> Of course there's a lot of instances where I've gone and violated my own standards, e.g. 9137a88b58dcfad57570461bb94e82f29a17d642.
20140326 23:32:06< shadowm> But that's because I can use and abuse my privileges with code I maintain, especially at such an early point in the development cycle (pre 1.11.0)
20140326 23:32:31< shadowm> If that commit was intended to be reviewed by a third party I would certainly have broken it down into smaller units.
20140326 23:33:15< shadowm> And in the end not doing things step-by-step did bite my in the ass later when I realized too late that I forgot to bring back a code path I deleted.
20140326 23:33:27< shadowm> *me
20140326 23:33:33< Dugi> That's true.
20140326 23:33:45< Dugi> Hm, a pity I wasn't making backups.
20140326 23:33:54< shadowm> The backups are the commits themselves.
20140326 23:34:18< shadowm> That's why we use Git nowadays -- you can commit as much as you want locally (esp. to a local topic branch) before pushing upstream.
20140326 23:34:49< shadowm> You can even go back and edit, split, or join ('squash') your commits if you know the right Git spells.
20140326 23:35:04< Dugi> Well, should I make another branch, try to order the changes somehow and make another pull request?
20140326 23:35:34< shadowm> You can do that, or (preferably) do that on the same pull request branch.
20140326 23:36:02< shadowm> But I suppose the last part might not be too easy if you aren't familiarized with Git.
20140326 23:36:32 * shadowm leaves to hunt for food, later.
20140326 23:37:16< Dugi> I'll go to bed, it's too late here.
20140326 23:39:46-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 245 seconds]
20140326 23:40:09-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140326 23:49:43-!- mjs-de [~mjs-de@f048170213.adsl.alicedsl.de] has quit [Remote host closed the connection]
20140326 23:51:53-!- Dugi [93fbd156@gateway/web/freenode/ip.147.251.209.86] has quit [Ping timeout: 245 seconds]
20140326 23:55:17-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 240 seconds]
20140326 23:57:17-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
--- Log closed Thu Mar 27 00:00:34 2014