--- Log opened Sat Jun 14 00:00:19 2014
--- Day changed Sat Jun 14 2014
20140614 00:00:19< iceiceice> its much better to use composition, otherwise you get stuck with inflexible code that is also hard to udnerstand
20140614 00:00:32< iceiceice> i think it woudl be much better if PRSM were all just P
20140614 00:00:59< shadowm> Yeah, the 'why' above is really just rhetorical. I suspect the alternative might not have been even considered.
20140614 00:02:05-!- Spoffy [~chatzilla@152.78.175.8] has quit [Ping timeout: 272 seconds]
20140614 00:02:07< iceiceice> yeah i mean there's many other decisions like this that have been made
20140614 00:02:34< iceiceice> i'm sure that adding the editor to the game would have been 10 times easier if it had not been decided to add a "resources::" name space and write all the code so that if any of those things is missing you get a segfault
20140614 00:03:40< iceiceice> but theres no use complaining, all you can do is incrementally improve things
20140614 00:03:57< iceiceice> we're stuck with what we have, if the *controllers go away, we don't have a game
20140614 00:04:04< iceiceice> if the resources:: go away, we don't have a game
20140614 00:04:18< shadowm> Sometimes a little re-structuring is needed if you want to make a step forward without everything collapsing on you, though.
20140614 00:04:35< iceiceice> yeah but you also can't say "i'm not going to do anything until i understand everything"
20140614 00:05:16< iceiceice> i dont think gfgtdf and i are particularly experts on the play controller, i'm not sure if i have a better idea how it works now than i did 3 months ago
20140614 00:05:17< shadowm> Yeah, I guess the core of the game experience is a different beast to deal with anyway.
20140614 00:05:33< iceiceice> but i am willing to look at it, say "hmm this makes no sense" and just change it
20140614 00:05:39< iceiceice> and the unit tests help me to stop from breaking anything
20140614 00:06:02< iceiceice> seriously ive made like 500 commits in the last 2 months, with surprisingly few breaks on master
20140614 00:06:47-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140614 00:09:23-!- Kexoth [~kex@93-137-12-32.adsl.net.t-com.hr] has quit [Remote host closed the connection]
20140614 00:11:25< shadowm> Ivanovic: 1.11.16 when? I'm a little concerned about a regression from 1.11.13 we have fixed that generally makes debugging WML much harder (commit 0751431d7d310c6e8df71c88c99d6d4d09d159e9).
20140614 00:11:40< shadowm> The regression in question is in 1.11.15.
20140614 00:12:16-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140614 00:23:37< iceiceice> gfgtdf: did you ever look at any of this "scoped_recall_unit" code?
20140614 00:24:06< iceiceice> these lines like: src/actions/create.cpp:				scoped_recall_unit this_unit("this_unit", save_id, &recall_unit - &recall_list[0]);
20140614 00:24:13< gfgtdf> iceiceice: hm yes i think there is a bug with it
20140614 00:24:19< iceiceice> it looks totally broken to me
20140614 00:24:34< iceiceice> scoped_recall_unit wants to get an unsigned int argument that tells it what position in the recall list it is
20140614 00:24:40< iceiceice> this code assumes that size_of unit = 1
20140614 00:25:01< gfgtdf> iceiceice: :/ hm the last time i ckeched that code wokred in most situations
20140614 00:25:40< iceiceice> idk im just looking at it now, i thoguht maybe im issing something
20140614 00:25:55< gfgtdf> iceiceice: i had recelent a discussion with Necospus (sry don't remember name) about a bug that was relates to wring psitions
20140614 00:26:04< gfgtdf> wrong*
20140614 00:26:51< gfgtdf> iceiceice: oh i only testes teh noral coped unit thought
20140614 00:26:56< gfgtdf> not teh recall one
20140614 00:28:10< gfgtdf> iceiceice: yes that indeed does not look good
20140614 00:28:24< gfgtdf> hm but
20140614 00:28:39< gfgtdf> why do you think sizeof unit = 1 ?
20140614 00:28:46< gfgtdf> iceiceice: ^
20140614 00:28:58< iceiceice> so as i understand the result of & recall_unit - & recall_list [0]
20140614 00:29:11< iceiceice> will be like, index of recall_unit * size_of(unit)
20140614 00:29:22< iceiceice> because thats the difference of the two memory addresses
20140614 00:29:34< gfgtdf> no the - perator doesnt measure in bytes
20140614 00:29:42< gfgtdf> it measures in siteof(T)
20140614 00:29:42< iceiceice> oh it corrects it for the type?
20140614 00:29:52< iceiceice> i didnt actually know that, i never use this pointer arithmetic 
20140614 00:30:10< iceiceice> and you can assume vector is implemented as an array i guess?
20140614 00:30:21< gfgtdf> i think yes
20140614 00:30:40< gfgtdf> still i dont see a reason against passing an id instead
20140614 00:30:47< iceiceice> yeah idk
20140614 00:31:00< iceiceice> what happens if you have two pointers that aren't aligned and you subtract?
20140614 00:31:09< iceiceice> does it like round or something :O
20140614 00:31:22< gfgtdf> iceiceice: hm idk 
20140614 00:31:47< gfgtdf> iceiceice:  i assume yes
20140614 00:32:04< gfgtdf> iceiceice: since thats was integer devision by default does.
20140614 00:32:14< iceiceice> yeah
20140614 00:33:06< gfgtdf> iceiceice: still id considerf this pointerarethmetk deangerous
20140614 00:33:09< gfgtdf> i'd
20140614 00:33:36< iceiceice> yeah i dont think it works with the smart pointers
20140614 00:33:39< iceiceice> im goign to have to change it somehow
20140614 00:34:02< gfgtdf> iceiceice: just pass the smartpointer?
20140614 00:34:16< iceiceice> can you subtract smart pointers though?
20140614 00:34:19< gfgtdf> no
20140614 00:34:25< iceiceice> y i didnt think so
20140614 00:34:35< iceiceice> oh
20140614 00:34:46< gfgtdf> i mena changing teh argument of the methos instead of "index in teh recall list of the unit" to "smaprtpointer to the unit"
20140614 00:37:17< gfgtdf> iceiceice: ^
20140614 00:37:43< iceiceice> y so i dont want to change scoped_unit if i dont have to atm
20140614 00:37:47< iceiceice> eventually that would be better
20140614 00:37:57< iceiceice> im just goign to use "find_ifmatches_id" to get an iterator
20140614 00:38:01< iceiceice> and subtract it from begin()
20140614 00:38:46< gfgtdf> :/ sounds even more hacks
20140614 00:38:49< gfgtdf> hacky*
20140614 00:39:08< gfgtdf> but ofc it's ok if its temporary
20140614 00:42:49< gfgtdf> iceiceice: is there sonehwere a list were all units (that means recalllist + units on map) are ?
20140614 00:43:22< iceiceice> no
20140614 00:43:34-!- travis-ci [~travis-ci@ec2-54-197-97-199.compute-1.amazonaws.com] has joined #wesnoth-dev
20140614 00:43:34< travis-ci> [travis-ci] gfgtdf/wesnoth-old#146 (gamestate_refactor - fe53e4c : gfgtdf): The build was broken.
20140614 00:43:34< travis-ci> [travis-ci] Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/27540338
20140614 00:43:34-!- travis-ci [~travis-ci@ec2-54-197-97-199.compute-1.amazonaws.com] has left #wesnoth-dev []
20140614 00:43:36< iceiceice> you have just to iterate over the map and then over the teams' recall lists
20140614 00:44:49-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140614 00:45:52< iceiceice> yeah this unit_map thing is a huge pain in the ass
20140614 00:46:01< iceiceice> i thoguht about it for a while now, theres like two ways to go i think
20140614 00:46:13< iceiceice> 1 is like, switch modules over to use smart pointers one at a time,
20140614 00:46:27< iceiceice> but if you do that, its a big problem because when you pass to a module that's not switched over you have to not delete the unit
20140614 00:46:44< iceiceice> idk if there is any way to do that other than like make a custom deleter or something, that would exist only for the refactor
20140614 00:46:54< iceiceice> the other way is to just switch all modules over at once
20140614 00:47:14< iceiceice> i think option (2) is actually the way to go, at least i'm willing to try it
20140614 00:48:44< gfgtdf> iceiceice: which module coudl you mena has not switche over ?
20140614 00:49:02< iceiceice> so theres 3 things
20140614 00:49:04< iceiceice> (1) unit_map
20140614 00:49:07< iceiceice> (2) teams recall list
20140614 00:49:09< iceiceice> (3) lua units
20140614 00:49:30< iceiceice> they all can trade unit pointers around between eachother,
20140614 00:49:38< gfgtdf> iceiceice: so whats teh problem which switching all of tehn to use shared_ptr ?
20140614 00:49:41< iceiceice> if any of them doesn't use a smart pointer then stuff is going to get deleted 
20140614 00:49:42< gfgtdf> them*
20140614 00:49:46< iceiceice> gfgtdf: its just more complicated
20140614 00:49:56< iceiceice> i would rather to only change a few files at a time and then test
20140614 00:49:58-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20140614 00:50:21< iceiceice> but at the end of the day theres like 100 unit tests that will blow up if the unit_map stops working
20140614 00:50:35< iceiceice> so its probably okay to switch it all over at once even if you want to be very cautious about things
20140614 00:56:26-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140614 00:57:02< iceiceice> gfgtdf: its sort of wierd that the undo code has separate constructors for config and also for unit &
20140614 00:57:08< iceiceice> shouldn't that just be like, determiend by the caller?
20140614 00:57:24-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140614 00:57:35< gfgtdf> iceiceice: hm i dont understand
20140614 00:57:51< iceiceice> idk i would think that it would be better to have one function
20140614 00:58:01< iceiceice> and if you have a config and not a unit then explicitly construct a unit
20140614 00:58:03< iceiceice> or smth liek this
20140614 00:58:29< iceiceice> idk all the places where this code is called though, maybe thats not good
20140614 00:59:58< gfgtdf> iceiceice: hm i tihnk contructing a unit might be expensive or have unwanted side effects
20140614 01:01:20< gfgtdf> iceiceice: do you have any idea how to fix this bug: https://gna.org/bugs/?22173 ?
20140614 01:03:29< iceiceice> gfgtdf: i dont think that the fog should make the units not appear
20140614 01:03:42< iceiceice> there is only one unit_map ever
20140614 01:04:01< iceiceice> besides units_start in the replay viewer
20140614 01:04:11< iceiceice> if the units aren't in it they aren't anywhere
20140614 01:04:25< iceiceice> what scenario reproduces this?
20140614 01:04:30< gfgtdf> iceiceice: but it looks liek the draw code or domw other ui cod emodifies it
20140614 01:04:54< gfgtdf> iceiceice: my modification which i use to test campaign causes this
20140614 01:05:18< gfgtdf> iceiceice: i can upload to addonserver if you want
20140614 01:05:34< iceiceice> hmm ok
20140614 01:05:40< iceiceice> when i read the title i misunderstood
20140614 01:06:19< iceiceice> this is super bizarre
20140614 01:06:25< iceiceice> so you are modifying the game_state during a report generation?
20140614 01:06:35< gfgtdf> yes
20140614 01:06:37< iceiceice> i think that should be emphatically disallowed
20140614 01:06:49< gfgtdf> iceiceice: nah i want it to be possible
20140614 01:06:49< iceiceice> report is just supposed to give info
20140614 01:06:59< iceiceice> its so crazy though
20140614 01:07:12< iceiceice> so the code that is like, drawing text panels on the side of the game viewer,
20140614 01:07:17< iceiceice> can be like killing units and ending the game?
20140614 01:07:35< gfgtdf> iceiceice: yes http://wiki.wesnoth.org/LuaWML:Display#wesnoth.theme_items
20140614 01:08:05-!- travis-ci [~travis-ci@ec2-75-101-244-139.compute-1.amazonaws.com] has joined #wesnoth-dev
20140614 01:08:05< travis-ci> [travis-ci] gfgtdf/wesnoth-old#147 (gamestate_refactor - e3c66c0 : gfgtdf): The build was broken.
20140614 01:08:05< travis-ci> [travis-ci] Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/27541792
20140614 01:08:05-!- travis-ci [~travis-ci@ec2-75-101-244-139.compute-1.amazonaws.com] has left #wesnoth-dev []
20140614 01:08:12< iceiceice> i have no idea how to fix it
20140614 01:08:42< iceiceice> i didnt think it was possible to call check_victory in that code path
20140614 01:09:26< iceiceice> gfgtdf: i tried to refactor all the report generation code yesterday,
20140614 01:09:37< iceiceice> the normal repotrs in reports.cpp don't use any resources pointers anymore,
20140614 01:09:46< iceiceice> instead they take a bundle of pointers given to them by the display object
20140614 01:09:59< iceiceice> the reason for this is, it makes it really hard to make the editor work without segfaulting otherwise
20140614 01:10:07< iceiceice> i guess that fabi had to write some really ugly and complicated code
20140614 01:10:17< iceiceice> and when i touched any of it it began to segfault anyways
20140614 01:10:29< iceiceice> but it is working now
20140614 01:10:41< iceiceice> im not sure if the refactor is done, theres now two things, 
20140614 01:10:45< iceiceice> report_context and display_context
20140614 01:10:50< iceiceice> i think actually they should be one thing
20140614 01:10:56< iceiceice> but im leaving it or now
20140614 01:11:01< iceiceice> but lua also is sort of crazy,
20140614 01:11:12< iceiceice> i had to make a context for lua to use, but it actually just ignroes it and does what it wants
20140614 01:11:20-!- shadowm_desktop2 [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20140614 01:11:43< iceiceice> i think it woudl be better if the reports were simpler though
20140614 01:11:49< iceiceice> whats the benefit of letting reports modify the gamestate?
20140614 01:12:02< gfgtdf> iceiceice: i uploaded my addon with the name TEST make eays
20140614 01:12:06< iceiceice> what can you do with that that you couldn't do otherwise?
20140614 01:13:07-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 245 seconds]
20140614 01:13:30< gfgtdf> iceiceice: i used it to emulate an unsynced "mouse move" event (or rather mouse enter hex)
20140614 01:17:31< gfgtdf> iceiceice: even if it not about check_victory people migth also want to get real information about the unit map from lua to draw tthings which is what theme_items is for
20140614 01:17:51< iceiceice> y but they normally wouldnt have to change the units ont he map to do that
20140614 01:18:20< gfgtdf> iceiceice: yes but it would still brak if they get wrong information
20140614 01:18:31< gfgtdf> iceiceice: alhough it would mose lilley be only viual bug then
20140614 01:18:34< gfgtdf> most*
20140614 01:18:54< gfgtdf> visual*
20140614 01:19:04< gfgtdf> iceiceice: also i dont checke teh unit_map eogjher
20140614 01:19:07< gfgtdf> eigher*
20140614 01:19:13< gfgtdf> change*
20140614 01:19:38< gfgtdf> iceiceice: (but i think elvishpilgaer does?)
20140614 01:22:40< iceiceice> hmm well
20140614 01:24:15< iceiceice> i dont see anything wrong to get the unit map and even to change animation properties of units but if people start killing units and such in the report code
20140614 01:24:24< iceiceice> i dont see how ti can be expected to work
20140614 01:24:32< iceiceice> its amazing to me that it is synced
20140614 01:25:09< iceiceice> if my plan to make a pathfinding data structure comes to fruition i guess this code would also have to trigger pathfinding updates?
20140614 01:25:19< iceiceice> i would rather only to give const access to the unit_map
20140614 01:25:34< iceiceice> i guess lua will be able to do whatever it normally does anyways...
20140614 01:25:48< iceiceice> idk
20140614 01:26:01< iceiceice> why dont you just make a regular "mouse hex enter" event?
20140614 01:26:08< iceiceice> or like, not even a wml event
20140614 01:26:11< iceiceice> like a lua only event
20140614 01:26:19< iceiceice> allow users to hook a lua function to mouse hex enter
20140614 01:26:51< iceiceice> it will be so hard to debug event code that is firing only inside of these play_slice report generation calls
20140614 01:27:58-!- sachith500 [~kvirc@112.134.112.25] has joined #wesnoth-dev
20140614 01:29:57< gfgtdf> iceiceice: hm well i think making const acces would be hard to implement and wouldnt fix the problem, that is having wrong information if i am correct.
20140614 01:30:38< iceiceice> how would you have wrong information?
20140614 01:30:53< gfgtdf> iceiceice: a "mouse hex enter" lua event would be enogh for my problem, but i think there a re still cases where it woudl not
20140614 01:31:51-!- sachith500 [~kvirc@112.134.112.25] has quit [Read error: Connection reset by peer]
20140614 01:31:53< gfgtdf> iceiceice: it currently looks like i get gefeates because this loop: https://github.com/wesnoth/wesnoth/blob/master/src/play_controller.cpp#L1394 only gives seeable units
20140614 01:32:01< gfgtdf> iceiceice: ofc i could be wrong
20140614 01:32:07-!- sachith500 [~kvirc@112.134.112.25] has joined #wesnoth-dev
20140614 01:32:07< gfgtdf> defeated*
20140614 01:32:15< gfgtdf> iceiceice: which is what i cann wrong information
20140614 01:32:20< gfgtdf> call*
20140614 01:33:17< gfgtdf> iceiceice: we for example we could try to implementz a "radar" ability which gives a message about how many enemy units are near in teh sideebar, imeplemnted with theme_items
20140614 01:33:36< gfgtdf> iceiceice: if i am correct that wouldnt wokr wigher
20140614 01:33:41< gfgtdf> eigher*
20140614 01:35:23< iceiceice> gfgtdf: i think that loop gives all the units
20140614 01:35:40< gfgtdf> iceiceice: hm ok, i'll debug more then
20140614 01:35:44< iceiceice> there is some code about "whiteboard::future_map"
20140614 01:35:47< gfgtdf> test again that means*
20140614 01:35:52< iceiceice> that modifies the unit_map i think
20140614 01:35:57< iceiceice> it is some scoped RAII thing
20140614 01:36:12< iceiceice> its supposed to restore the state to the white board planned state
20140614 01:36:14< iceiceice> and change it back
20140614 01:36:17< iceiceice> when it is destroyed
20140614 01:36:24< iceiceice> imo its too complicated though
20140614 01:39:19< gfgtdf> iceiceice: that is also actoive if i dont use whiteboard ?
20140614 01:39:31< gfgtdf> active*
20140614 01:39:57< iceiceice> im not really sure
20140614 01:46:50< gfgtdf> iceiceice: hm it seems wrong that the whiteboard which is part of the ui changes the gamestate
20140614 01:47:00< iceiceice> whitboard it not part of ui
20140614 01:47:23< gfgtdf> iceiceice: id say it is
20140614 01:47:25< gfgtdf> i'd
20140614 01:47:29< iceiceice> nah because it change the game state
20140614 01:47:45-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20140614 01:48:07-!- iceiceice_ [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140614 01:48:07-!- iceiceice_ [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Changing host]
20140614 01:48:07-!- iceiceice_ [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20140614 01:48:19< iceiceice_> gfgtdf: how is it aht you turn on planning mode
20140614 01:48:23< iceiceice_> click to move a unit
20140614 01:48:31< iceiceice_> and suddenly all the pathfinding takes place as though you already moved it?
20140614 01:48:38< iceiceice_> its because it is changing the unit_map
20140614 01:48:49< iceiceice_> it's changing the context in which the entire rest of the engine oeprates
20140614 01:49:02< iceiceice_> and it uses all this fancy RAII to do the "switcheroo" without you noticing
20140614 01:49:13< gfgtdf> iceiceice_: hm i thin pathfinign is also ui
20140614 01:49:15< iceiceice_> except when it doesnt work and you segfault :O
20140614 01:49:24< iceiceice_> pathfinding is definitely part fot he engine
20140614 01:49:30< iceiceice_> you can query pathfinding directly in lua / wml
20140614 01:49:34< iceiceice_> and it's used extensively by ai
20140614 01:50:06< iceiceice_> i think it shuold be different though
20140614 01:50:48< gfgtdf> hm from the mp sync point of view (that is my default view) it is usualy wrong to change  the gamestate form an unsynced context.
20140614 01:56:27-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20140614 01:56:56< iceiceice_> i would think that it's wrong for ui to change the gamestate at all
20140614 01:57:09< gfgtdf> iceiceice_: will the unit test also fail with warnings or just with errors ?
20140614 01:57:58< gfgtdf> iceiceice_: the strict mode thing i mean
20140614 01:58:11< iceiceice_> if you set log-strict=warning it will fail with warning and error
20140614 01:58:17< iceiceice_> thats what travis is set to atm
20140614 01:58:35-!- Kexoth [~kex@93-137-12-32.adsl.net.t-com.hr] has joined #wesnoth-dev
20140614 01:59:02< iceiceice_> http://c2.com/cgi/wiki?ModelViewController
20140614 02:00:40< iceiceice_> i think it would be better if there were actually two more hierarcheis in the play_controller state,
20140614 02:00:43< iceiceice_> *two more objects
20140614 02:00:58< iceiceice_> i think there shoudl be a game_state, and also an "game_application_state" or something like this
20140614 02:01:33< iceiceice_> the game_application should be where things happen that shouldn't happen from the play_controller but also not in the game_state,
20140614 02:01:37< iceiceice_> so like transforming the game_State to a view 
20140614 02:01:48< iceiceice_> or, allowing the whiteboard to mediate that process
20140614 02:02:17< iceiceice_> because there is some info we have that is needed to be part of the state but its not properly part of the game state
20140614 02:02:23< iceiceice_> but its also very messy to have that stuf in play_controller
20140614 02:02:27< iceiceice_> because play_controller is already enormous
20140614 02:02:34< iceiceice_> and handles all of the hotkeys and command line comamnds
20140614 02:03:06< iceiceice_> i think hotkeys is more or less the only thing that the play_controller should actually do
20140614 02:03:08-!- Kexoth [~kex@93-137-12-32.adsl.net.t-com.hr] has quit [Ping timeout: 252 seconds]
20140614 02:03:26< iceiceice_> that and some initialization i guess
20140614 02:04:39< gfgtdf> iceiceice_: hm ok i think my pr about mp is more or less ready, but i'll still do some testing
20140614 02:09:05-!- Ivanovic_ [~ivanovic@frnk-5f751ef4.pool.mediaWays.net] has joined #wesnoth-dev
20140614 02:11:01-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140614 02:12:03-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 240 seconds]
20140614 02:12:58-!- Ivanovic_ is now known as Ivanovic
20140614 02:21:02-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20140614 02:22:13< gfgtdf> i go to sleep now
20140614 02:22:14-!- gfgtdf [~chatzilla@f054147096.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 29.0.1/20140506152807]]
20140614 02:26:16-!- iceiceice_ [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20140614 02:34:16-!- travis-ci [~travis-ci@ec2-54-197-97-199.compute-1.amazonaws.com] has joined #wesnoth-dev
20140614 02:34:16< travis-ci> [travis-ci] gfgtdf/wesnoth-old#148 (gamestate_refactor - e60f29c : gfgtdf): The build is still failing.
20140614 02:34:16< travis-ci> [travis-ci] Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/27544538
20140614 02:34:16-!- travis-ci [~travis-ci@ec2-54-197-97-199.compute-1.amazonaws.com] has left #wesnoth-dev []
20140614 02:39:03-!- Upth [~ogmar@108-85-89-233.lightspeed.frokca.sbcglobal.net] has quit [Disconnected by services]
20140614 02:39:16-!- Upth [~ogmar@108-85-89-233.lightspeed.frokca.sbcglobal.net] has joined #wesnoth-dev
20140614 02:39:43-!- _8680_ [~8680@2002:4404:712c:0:d5f4:c603:6f99:102d] has quit [Ping timeout: 252 seconds]
20140614 02:42:34-!- _8680_ [~8680@2002:4404:712c:0:20e5:e19e:94f7:c5b7] has joined #wesnoth-dev
20140614 02:47:56-!- Spoffy [~chatzilla@152.78.175.8] has joined #wesnoth-dev
20140614 02:58:24-!- sachith500 [~kvirc@112.134.112.25] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140614 02:58:57-!- sachith500 [~kvirc@112.134.112.25] has joined #wesnoth-dev
20140614 03:02:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 03:06:27-!- sachith500 [~kvirc@112.134.112.25] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140614 03:08:48-!- sachith500 [~kvirc@112.134.112.25] has joined #wesnoth-dev
20140614 03:10:32-!- sachith500 [~kvirc@112.134.112.25] has quit [Client Quit]
20140614 03:16:19-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Ping timeout: 240 seconds]
20140614 03:17:07-!- sachith500 [~kvirc@112.134.112.25] has joined #wesnoth-dev
20140614 03:29:49-!- Spoffy [~chatzilla@152.78.175.8] has quit [Ping timeout: 272 seconds]
20140614 03:47:20-!- Kexoth [~kex@93-137-12-32.adsl.net.t-com.hr] has joined #wesnoth-dev
20140614 03:51:59-!- Kexoth [~kex@93-137-12-32.adsl.net.t-com.hr] has quit [Ping timeout: 272 seconds]
20140614 04:01:22< Necrosporus> I think there's a bug in EI #11 Captured
20140614 04:01:48< Necrosporus> Dacyn's robe doesn't change team color when he's rescued
20140614 04:01:54< Necrosporus> though it might be intentional
20140614 04:03:57-!- molgrum [~molgrum@212.85.89.43] has quit [Ping timeout: 245 seconds]
20140614 04:10:10-!- Kexoth [~kex@93-137-12-32.adsl.net.t-com.hr] has joined #wesnoth-dev
20140614 04:14:53-!- Kexoth [~kex@93-137-12-32.adsl.net.t-com.hr] has quit [Ping timeout: 264 seconds]
20140614 04:17:23-!- iceiceice_ [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20140614 04:17:29-!- riksteri [~riksteri@dsl-tkubrasgw3-54f96b-216.dhcp.inet.fi] has joined #wesnoth-dev
20140614 04:22:17-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Cheers]
20140614 04:54:26-!- shadowm_desktop2 is now known as shadowm_desktop
20140614 05:16:20-!- Guest22059 [~cib@p5DD22D04.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140614 05:17:41< irker485> wesnoth: Ignacio R. Morelle wesnoth:master 65570f5cb9e9 / src/campaign_server/ (campaign_server.cpp campaign_server.hpp): campaignd: Replace vector<pair<k,v>> with map<k,v> for the handlers table http://git.io/r11guw
20140614 05:32:05-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20140614 05:44:02-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140614 05:46:57< vultraz> What happened to the Copy Selected Coordinates to Keyboard editor function? I
20140614 05:47:15< shadowm> If somebody knows what the "ordered" means in config::ordered_begin() and friends, please tell me so I can give you a hug or something.
20140614 05:49:15< shadowm> For now I'll assume it means absolutely nothing and that given a config with children { [a], [a], [b], [b], [c], [c] } there is no guarantee that [a] or which [a] corresponds to *ordered_begin().
20140614 05:50:24< shadowm> vultraz: I think fabi killed it because it was purportedly superseded by area declarations.
20140614 05:50:49< vultraz> shadowm: don't area declarations still need a SLF
20140614 05:50:51-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140614 05:50:52< shadowm> I remember asking him about it but I don't remember what the outcome of the discussion was. Perhaps I was supposed to resurrect it.
20140614 05:50:59< shadowm> Yes but see the scenario editor.
20140614 05:51:34< shadowm> src/hotkey/hotkey_command.cpp:  { hotkey::HOTKEY_EDITOR_SELECTION_EXPORT, "editor-export-selection-coords", N_("Export Selected Coordinates to System Clipboard"), true, hotkey::SCOPE_EDITOR, "" },
20140614 05:51:39< shadowm> It still exists, actually.
20140614 05:52:09< shadowm> Perhaps it's just missing from the menus? In that case, try binding a hotkey sequence for it.
20140614 05:55:18< vultraz> It seems Areas are only for TODs...
20140614 05:55:38< vultraz> Create one, save the scenario, what do you get:
20140614 05:55:39< vultraz> [time_area]
20140614 05:56:18< vultraz> I thought they were going to be id specified SLFs you could use for filtering
20140614 05:57:21< shadowm> You can actually use them for SLFs.
20140614 05:58:06< shadowm> "area: (Version 1.11.8 and later only) matches locations assigned to the [time_area] with the given id." <http://wiki.wesnoth.org/StandardLocationFilter>
20140614 06:04:30-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 255 seconds]
20140614 06:07:13-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20140614 06:16:33< Necrosporus> http://www.tempsend.com/FEF98781C0/5896
20140614 06:16:45< Necrosporus> There's a problem in Wesnoth GUI
20140614 06:18:20-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 252 seconds]
20140614 06:19:26-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20140614 06:32:27< c74d> Necrosporus, <http://www.tempsend.com/FEF98781C0/5896> returns status 404 Not Found for me.
20140614 06:33:18< Necrosporus> http://www.tempsend.com/FEF98781C0
20140614 06:35:29-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140614 06:36:37-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140614 06:41:52-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 255 seconds]
20140614 06:48:59-!- Sulfur [~Miranda@p5B008377.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140614 06:52:29-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140614 06:52:53-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 244 seconds]
20140614 06:53:50-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20140614 07:34:25-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140614 07:35:56-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140614 07:48:43-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140614 07:53:35-!- trademark_ [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has joined #wesnoth-dev
20140614 07:59:53-!- c74d [~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766] has quit [Excess Flood]
20140614 08:03:58-!- c74d [~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766] has joined #wesnoth-dev
20140614 08:04:30-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20140614 08:09:17-!- thunderstruck [~zaibotren@cpc7-cowc7-2-0-cust670.14-2.cable.virginm.net] has joined #wesnoth-dev
20140614 08:09:51< thunderstruck> 20140613 18:22:18< gfgtdf> thunderstruck: do you know why here: https://github.com/wesnoth/wesnoth/blob/7154ab4609afb1524f96e87982aadd655b1cad80/src/multiplayer_connect_engine.cpp#L874 we update teh controllers before we adjust the controller values ("network" -> "human") ?
20140614 08:10:25< thunderstruck> So that controller options array would be populated before we start setting any options.
20140614 08:12:11-!- EdB [~edb@85.69.242.6] has joined #wesnoth-dev
20140614 08:16:27-!- Sulfur [~Miranda@p5B008377.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20140614 08:17:03-!- Ivanovic [~ivanovic@frnk-5f751ef4.pool.mediaWays.net] has quit [Changing host]
20140614 08:17:03-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20140614 08:22:37-!- EdB [~edb@85.69.242.6] has quit [Quit: Konversation terminated!]
20140614 08:24:06< vultraz> Nice to see RiftWalker's project is proceeding
20140614 08:38:53-!- Haudegen_ [~quassel@178.115.128.160.wireless.dyn.drei.com] has joined #wesnoth-dev
20140614 08:40:28-!- Haudegen_ is now known as Haudegen
20140614 08:45:24-!- cib_ [~cib@p5DD22616.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140614 08:48:45-!- Guest22059 [~cib@p5DD22D04.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20140614 08:56:31-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140614 08:58:54< zookeeper> RiftWalker, uh, when your PR adds defines to all mainline MP scenarios, doesn't that mean that whenever you start one of those, you'll have to go through an extra loading screen? that doesn't sound like a good idea to me.
20140614 09:00:40< zookeeper> or rather, an extra parsing/preprocessing thingy, i guess there'd be a brief loading screen anyway.
20140614 09:01:10-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140614 09:09:59-!- Sulfur [~Miranda@p5B008377.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140614 09:13:05-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 264 seconds]
20140614 09:16:16-!- mjs-de [~mjs-de@f048075239.adsl.alicedsl.de] has joined #wesnoth-dev
20140614 09:23:28< zookeeper> RiftWalker, i presume the idea is that because the eras already use the feature, an extra loading phase will be required anyway so you might as well do it for the schedule and playlist etc of each scenario anyway
20140614 09:29:01-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140614 09:41:27-!- Haudegen [~quassel@178.115.128.160.wireless.dyn.drei.com] has quit [Ping timeout: 245 seconds]
20140614 09:45:31-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20140614 10:09:38< Necrosporus> Is EI #12 Evacuation even possible on hard?
20140614 10:11:32-!- sachith500|2 [~kvirc@112.135.143.120] has joined #wesnoth-dev
20140614 10:14:03-!- sachith500 [~kvirc@112.134.112.25] has quit [Ping timeout: 240 seconds]
20140614 10:14:41< Necrosporus> There are three bands of orcs from all sides and they all have over 200 gold each
20140614 10:17:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 10:19:58-!- Haudegen [~quassel@178.115.128.160.wireless.dyn.drei.com] has joined #wesnoth-dev
20140614 10:20:26-!- sachith500|2 [~kvirc@112.135.143.120] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140614 10:31:59-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140614 10:32:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 10:59:13-!- Jetrel_ [~Jetrel@c-75-73-180-126.hsd1.mn.comcast.net] has joined #wesnoth-dev
20140614 11:01:18-!- Jetrel [~Jetrel@c-75-73-180-126.hsd1.mn.comcast.net] has quit [Ping timeout: 276 seconds]
20140614 11:05:06-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140614 11:07:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 11:15:54-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140614 11:31:17-!- Spoffy [~chatzilla@152.78.175.8] has joined #wesnoth-dev
20140614 11:42:33-!- Spoffy [~chatzilla@152.78.175.8] has quit [Ping timeout: 272 seconds]
20140614 11:52:53-!- aquileia [2edf50c1@gateway/web/freenode/ip.46.223.80.193] has joined #wesnoth-dev
20140614 12:13:38-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20140614 12:13:54< mordante> servus
20140614 12:26:17-!- molgrum [~molgrum@212.85.89.43] has joined #wesnoth-dev
20140614 12:28:01-!- Spoffy [~chatzilla@152.78.175.8] has joined #wesnoth-dev
20140614 12:31:18-!- iceiceice_ [~chris@wesnoth/developer/iceiceice] has quit [Ping timeout: 244 seconds]
20140614 12:36:44< aquileia> What was the official procedure for minor fixes in strings? E.g. changing ... to a proper ellipsis? Do I list it somewhere for after the freeze?
20140614 12:37:02< aquileia> Or isn't it worth the trouble at all?
20140614 12:37:20< Necrosporus> zookeeper, what do you think?
20140614 12:38:36< Necrosporus> Even valley of death from httt is easier, as there at least some distance from enemy keeps and you could press to one enemy avoiding others
20140614 12:43:34-!- aquileia [2edf50c1@gateway/web/freenode/ip.46.223.80.193] has quit [Ping timeout: 246 seconds]
20140614 12:44:15< irker485> wesnoth: Mark de Wever wesnoth:master 02b761b24eb6 / changelog data/gui/default/widget/toggle_panel_default.cfg: Set the minimum width for a listbox cell. http://git.io/4vCxIQ
20140614 12:48:39-!- sachith500 [~kvirc@112.135.143.120] has joined #wesnoth-dev
20140614 13:00:09-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20140614 13:06:56-!- sachith500 [~kvirc@112.135.143.120] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140614 13:10:04-!- aquileia [2edf50c1@gateway/web/freenode/ip.46.223.80.193] has joined #wesnoth-dev
20140614 13:10:07-!- sachith500 [~kvirc@112.135.143.120] has joined #wesnoth-dev
20140614 13:11:14-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140614 13:13:37-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140614 13:15:31< mordante> lipkab here is an example of using a stencil buffer in SDL2 https://gist.github.com/sealfin/d22f4ba4d1022e1b89dd
20140614 13:15:53-!- aquileia [2edf50c1@gateway/web/freenode/ip.46.223.80.193] has quit [Quit: Page closed]
20140614 13:16:10< mordante> lipkab this allows to render things in arbitrary shapes, but seems to require OGL functions
20140614 13:25:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 13:27:25-!- sachith500|2 [~kvirc@112.134.130.10] has joined #wesnoth-dev
20140614 13:28:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 13:30:05-!- sachith500 [~kvirc@112.135.143.120] has quit [Ping timeout: 252 seconds]
20140614 14:06:02-!- Haudegen [~quassel@178.115.128.160.wireless.dyn.drei.com] has quit [Ping timeout: 245 seconds]
20140614 14:16:15-!- Stumpfenstiel_ [~quassel@178.115.128.160.wireless.dyn.drei.com] has joined #wesnoth-dev
20140614 14:21:29-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Ping timeout: 264 seconds]
20140614 14:23:10-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has joined #wesnoth-dev
20140614 14:25:57-!- sachith500|2 [~kvirc@112.134.130.10] has quit [Read error: Connection reset by peer]
20140614 14:29:36-!- Stumpfenstiel_ is now known as Haudegen
20140614 14:30:06-!- Haudegen is now known as Guest74556
20140614 14:37:00-!- Guest74556 is now known as Haudegen
20140614 14:48:35-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140614 15:03:52< zookeeper> Necrosporus, i don't remember it as being _too_ hard. it's supposed to be a difficult one where you'll lose a lot of veterans.
20140614 15:09:17-!- aquileia [2edf50c1@gateway/web/freenode/ip.46.223.80.193] has joined #wesnoth-dev
20140614 15:12:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 15:16:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 15:23:03-!- sachith500|2 [~kvirc@112.134.250.252] has joined #wesnoth-dev
20140614 15:35:32< aquileia> noy: Where would you place the khalifate homelands on this map? https://github.com/aquileia/wesnoth-resources/blob/master/other/great_continent_latest.png
20140614 15:35:52-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140614 15:37:40< aquileia> The yellow horizontal stripe are the "Sandy Wastes", to their west  are the "Mountains of Peril", everything below isn't even named yet
20140614 15:38:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 15:40:17< aquileia> Am I correct if I assume that the valley with the two rivers is only a province of the khalifate and their main realm begins in the lower right edge?
20140614 15:41:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 15:42:01< zookeeper> i always intended for their whole empire to basically be around the bay and rivers
20140614 15:42:25< aquileia> ah, so you already planned them in?
20140614 15:42:38< zookeeper> that already is an area about the size of wesnoth, and they're a much smaller country
20140614 15:42:51< zookeeper> well i sketched the south with the khalifate in mind, yes
20140614 15:43:27< zookeeper> everything not already pictured in mainline maps (TSG, mostly) can of course be changed at whim if there's need
20140614 15:44:12< aquileia> The TSG map ends as I described - a tiny slice  of the mountains and thee sandy wastes
20140614 15:44:22< aquileia> as you know, of course
20140614 15:44:58< aquileia> I just would have imagined the desert separating them from Wesnoth to be broader
20140614 15:45:22-!- Kevin_Xi [~kevin@223.72.182.191] has joined #wesnoth-dev
20140614 15:46:01< zookeeper> i figured that their capital would probably be somewhere close to where the rivers flow into the bay, with some other cities scattered around the coast and riverbanks
20140614 15:46:08< aquileia> A little rotation so that it doesn't narrow down as mucht to the east would heelp with that, I guess
20140614 15:46:20< aquileia> *much
20140614 15:46:30< zookeeper> broader as in on the x axis?
20140614 15:46:38-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140614 15:47:31< aquileia> I mean a little more "height" at the eastern end
20140614 15:47:34-!- Haudegen [~quassel@178.115.128.160.wireless.dyn.drei.com] has quit [Remote host closed the connection]
20140614 15:47:59< zookeeper> right
20140614 15:48:25< zookeeper> well, i don't think there's need; it's still pretty inaccessible from wesnoth, which is the main point
20140614 15:48:43< zookeeper> either you have to make a really long detour to the east and then south, or you have to wade through the huge desert
20140614 15:48:50< aquileia> rotating the valley by about 15° so that the region between the two mountain ranges isn't that small
20140614 15:49:43< aquileia> or even 5°
20140614 15:50:36< Kevin_Xi> aquileia: Hi(sorry to interrupt). About PR #199. After merged that, the "doc/doxygen/html" is marked as untracked, is that expected?
20140614 15:50:37< aquileia> except of course if that upper mountain range (next to the bitter swamp) is in fact desert mountain
20140614 15:51:24< aquileia> Kevin_Xi: The gitignore shouldn't influence existing tracked files at all
20140614 15:51:39< zookeeper> i'm sure those mountains can be very inhospitable and hard to traverse, if necessary :p
20140614 15:53:02< aquileia> zookeeper: If that's the case, I'm fine with it. Thanks!
20140614 15:53:09-!- Haudegen [~quassel@178.115.128.160.wireless.dyn.drei.com] has joined #wesnoth-dev
20140614 15:53:45< aquileia> Kevin_Xi: https://github.com/wesnoth/wesnoth/commit/2ae18b4762ea2b9fd29ab5ebace7d80fdca74599
20140614 15:54:11< aquileia> Kevin_Xi: So it IS intended that you don't commit these
20140614 15:55:01< aquileia> If they appear in the list, that's weird...
20140614 15:55:26< Kevin_Xi> aquileia: you have deleted that line in your PR
20140614 15:55:49< aquileia> but i merged it into the root .gitignore
20140614 15:56:15< aquileia> https://github.com/wesnoth/wesnoth/blob/master/.gitignore#L138
20140614 15:57:02< Kevin_Xi> aquileia: yes I know, but before merged this, I don't have those files untracked
20140614 15:57:25< aquileia> I'm testing it right now...
20140614 16:01:36< aquileia> Kevin_Xi: For me they're properly ignored
20140614 16:04:06< aquileia> could you type "git status --ignored" and see where they appear? Untracked or ignored?
20140614 16:05:59< Kevin_Xi> aquileia: Untracked files:(use "git add <file>..." to include in what will be committed)
20140614 16:05:59< Kevin_Xi> doc/doxygen/html/ (I can't access pastebin for a while)
20140614 16:07:19-!- travis-ci [~travis-ci@ec2-54-83-145-33.compute-1.amazonaws.com] has joined #wesnoth-dev
20140614 16:07:19< travis-ci> [travis-ci] gfgtdf/wesnoth-old#149 (gamestate_refactor - f86fcd6 : gfgtdf): The build is still failing.
20140614 16:07:19< travis-ci> [travis-ci] Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/27570099
20140614 16:07:19-!- travis-ci [~travis-ci@ec2-54-83-145-33.compute-1.amazonaws.com] has left #wesnoth-dev []
20140614 16:07:32< aquileia> Kevin_Xi: I guess I know the issue - the ** syntax isn't supported by old git versions
20140614 16:07:58-!- gfgtdf [~chatzilla@f054147096.adsl.alicedsl.de] has joined #wesnoth-dev
20140614 16:08:17< Kevin_Xi> aquileia: my git is 1.7.9.5
20140614 16:08:23< gfgtdf> aquileia: do you use openmp in your msvc builds '?
20140614 16:08:56< aquileia> gfgtdf: I only know that I use the settings in the project file
20140614 16:09:18< aquileia> I don't know whether it's activated there
20140614 16:09:20< gfgtdf> aquileia: theose of te VC9 ?
20140614 16:09:25< aquileia> yes
20140614 16:09:40< gfgtdf> aquileia: do you often get high cpu useage in wesnoth even wioutut doing anything ?
20140614 16:09:55< gfgtdf> aquileia: in your self compiled version i mean
20140614 16:10:00< aquileia> Kevin_Xi: Seems it was introduced in 1.8.2
20140614 16:10:29< aquileia> gfgtdf: I never tested that
20140614 16:12:35< aquileia> gfgtdf: I have severe performance issues with debug build, but usually wesnoth idles at about 1% CPU
20140614 16:13:02< gfgtdf> aquileia: hm ok that most liley the my problem is a msvc 201 only issue
20140614 16:13:29< gfgtdf> 2010*
20140614 16:14:44< Kevin_Xi> aquileia: I see, thank you. Ubuntu 12.04 is still have 1.7.9 as latest version in its packages.
20140614 16:15:42< aquileia> Kevin_Xi: Sorry for that, I didn't know it was introduced rather recently
20140614 16:17:51< aquileia> You can fix it locally by listing it in .git/info/exclude (your local .gitignore), but of course that's subptimal
20140614 16:19:30< Kevin_Xi> aquileia: it is OK, I even don't know the gitignore is already has new syntax, I will update it.
20140614 16:21:22< aquileia> gfgtdf: Wait... now it takes one core without doing anything...
20140614 16:21:58-!- Kevin_Xi [~kevin@223.72.182.191] has quit [Quit: Zzz...]
20140614 16:22:07< gfgtdf> aquileia: did you change anything in the code between "taking 1%" and "taking 1 core" ?
20140614 16:22:33< aquileia> no
20140614 16:23:54< gfgtdf> aquileia: debug or release build ?
20140614 16:24:06-!- travis-ci [~travis-ci@ec2-50-16-123-177.compute-1.amazonaws.com] has joined #wesnoth-dev
20140614 16:24:06< travis-ci> [travis-ci] gfgtdf/wesnoth-old#150 (gamestate_refactor - 876327c : gfgtdf): The build was fixed.
20140614 16:24:06< travis-ci> [travis-ci] Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/27571261
20140614 16:24:06-!- travis-ci [~travis-ci@ec2-50-16-123-177.compute-1.amazonaws.com] has left #wesnoth-dev []
20140614 16:24:33-!- sachith500 [~kvirc@112.134.166.89] has joined #wesnoth-dev
20140614 16:24:38< aquileia> release build, eastern invasion: fullscreen 30%, windowed mode 50% = 1 core
20140614 16:26:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 16:27:29-!- sachith500|2 [~kvirc@112.134.250.252] has quit [Ping timeout: 264 seconds]
20140614 16:28:35< gfgtdf> aquileia: on msvc 2010 i had problem relateed to openmp which ar emost liley related to: http://social.msdn.microsoft.com/Forums/vstudio/en-US/3ba783fe-2e52-4511-b608-79708613f30b/useless-high-cpu-load-with-omp?forum=parallelcppnative         but i coundt find information on whether that bug still persits on msvc 2012
20140614 16:28:58-!- aquileia [2edf50c1@gateway/web/freenode/ip.46.223.80.193] has quit [Ping timeout: 246 seconds]
20140614 16:29:21< loonycyborg> official releases are made with mingw, not msvc :P
20140614 16:29:32< gfgtdf> ye i know
20140614 16:29:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 16:35:38< irker485> wesnoth: Mark de Wever wesnoth:master 15ab52d46013 / .gitignore: Ignore doc/doxygen/html in older versions of git. http://git.io/Vm0xnA
20140614 16:35:42< mordante> Kevin_Xi, aquileia, I also have that .gitignore issue, fixed ^, not even sure what the ** in there buys us
20140614 16:36:48< mordante> Aishiko, is there a reason you made those two commits in a different repository (looking at them now)
20140614 16:38:02-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140614 16:38:50< mordante> Aishiko, it would be nice if sprite_data would take a reference to a config and initialise the struct from that constructor
20140614 16:39:12< mordante> Aishiko, have a look at portrait.[ch]pp for an example
20140614 16:41:26< mordante> Aishiko, are you sure the code compiles? I see »while()« which will not compile
20140614 16:43:50< mordante> Aishiko, https://github.com/Aishiko/wesnoth/commit/1c7c8f97b473e1ce906e70d8665c2aa3f1be98bc
20140614 16:44:12-!- aquileia [2edf50c1@gateway/web/freenode/ip.46.223.80.193] has joined #wesnoth-dev
20140614 16:44:39< mordante> Aishiko, image.cpp the hunk starting at line 789 looks weird, it's a NOP
20140614 16:45:53< mordante> Aishiko, for you other questions in the mail I think it's easiest to discuss them on IRC
20140614 16:46:37< aquileia> mordante: As the /html directory doesn't exist for me (for obvious reasons) I couldn't be sure that that rule was only intended for that specific subdir. Thus I ported the rule in its exact sense (the ** means it'll ignore any html dir at any lower level)
20140614 16:47:06< aquileia> Now that I found the corresponding commit i agree it's unnecessary
20140614 16:48:09< mordante> yes I assumed ** would do that, some other tools (vim) use that syntax
20140614 16:48:50< mordante> I just wondered why it was added looking at the original commit
20140614 16:49:04< aquileia> Sure, given the commit it's clear
20140614 16:49:26< mordante> but no problem it now works for all versions of Git
20140614 16:49:37< mordante> not sure whether other rules also need to be adjusted
20140614 16:50:03< mordante> I only got bitten by the doxygen rule, since I run Doxygen locally
20140614 16:51:42< mordante> btw having one .gitignore is a nice improvement :-)
20140614 16:51:49< aquileia> In some cases (e.g. translations) the syntax is necessary, so it'd take a lot of time to search the history of 125 .gitignore files and - in case the commit isn't clear - speak with the maintainer
20140614 16:52:08< aquileia> mordante: It's not done yet - src/ still has some
20140614 16:52:46< aquileia> but shadowm wanted to test a self-written auto-merge script on it, I think
20140614 16:54:48< mordante> shadowm, I tested with the gamestate inspector 'fullscreen' in 1.12, but the result looks ugly so I won't commit it
20140614 16:58:11-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140614 17:01:05-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20140614 17:02:02-!- ancestral [~ancestral@12.23.74.29] has quit [Client Quit]
20140614 17:04:16< iceiceice> gfgtdf: i switched over the pointers but now one of the pathfinding tests became incredibly slow :/
20140614 17:04:35< iceiceice> i am trying to profile it now...
20140614 17:05:29< gfgtdf> iceiceice: hm you know whats t main operation that makes it slow? dereferencing pointer or copying pointer or somethign else ?
20140614 17:05:48< iceiceice> i have no idea yet
20140614 17:05:57< iceiceice> callgrind is taking forever
20140614 17:06:07< mordante> what's new ;-)
20140614 17:06:48< gfgtdf> iceiceice: i think shared ptr, unlike usual pointrs have a !=0 test on derefering for debugging, but idk whether that matter enough.
20140614 17:07:05< iceiceice> hmm i realized
20140614 17:07:11< iceiceice> there is a note on the boost page that
20140614 17:07:15< iceiceice> shared_ptr use count is slow?
20140614 17:07:19< iceiceice> but i dont think i am using it...
20140614 17:07:32< gfgtdf> iceiceice:  can you give  me a link ?
20140614 17:07:42< iceiceice> yeah not in this branch
20140614 17:07:44< mordante> shared_ptr has overhead since it needs to keep a reference count
20140614 17:07:54< iceiceice> mordante: maybe you can advise
20140614 17:08:01< iceiceice> i would like to try to fix this "double kill" bug
20140614 17:08:09< mordante> iceiceice, what is the code we talk about?
20140614 17:08:21< iceiceice> the way that the animation engine is set up, unit_animations have to hold a pointer to their unit
20140614 17:08:26< iceiceice> and the unit points back to them also
20140614 17:08:46< iceiceice> there is some bad thing that can happen where a unit is destroyed before the animation finishes
20140614 17:08:50< iceiceice> and we segfault
20140614 17:09:28< iceiceice> mattsc has reproduced by hitting ctrl-k very quickly to kill a unit during its kill animation, but also I guess elvish-pillager has made lua code that segfaults because of this
20140614 17:10:01< iceiceice> i have actually read most of the whiteboard code now at this point, i think that code is doing the right thing,
20140614 17:10:10< iceiceice> but i'm also somewhat concerned that it can happen with fake units too
20140614 17:10:41< iceiceice> it seems like the game_display object could potentially destroy units even if they still have animations
20140614 17:10:53< iceiceice> anyways i thought about this a few months ago and gave up
20140614 17:11:06< iceiceice> i thought to try again now, the idea would be to use shared_ptr's in all modules
20140614 17:11:16< iceiceice> and animations hold a weak_ptr to the unit
20140614 17:11:31< iceiceice> i guess its some performance hit but i'm not sure how significant it would be, its kind of hard to say
20140614 17:11:48< iceiceice> the unit_map already has this "unit_pod" for reference counting,
20140614 17:11:55< iceiceice> potentially htat could be completely replaced with a shared_ptr
20140614 17:12:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 17:12:18< iceiceice> and then the reference count could be used through all the modules
20140614 17:12:31< iceiceice> the whiteboard module actually makes a lot of use of smart pointers,
20140614 17:12:46< iceiceice> but it has to use auto_ptr, because that one has a "release" function it uses when it gives to some module that doesn't use smart pointers
20140614 17:14:07-!- sachith500 [~kvirc@112.134.166.89] has quit [Read error: Connection reset by peer]
20140614 17:14:17< iceiceice> anyways in my branch i'm trying to make more or less everything (right now its unit map, lua units, and team recall list) to use shared_ptr
20140614 17:14:24-!- sachith500 [~kvirc@112.134.166.89] has joined #wesnoth-dev
20140614 17:14:25< iceiceice> and this has the consequence that ai and whiteboard use this also
20140614 17:14:36< iceiceice> and i guess some the recall dialog
20140614 17:14:54< iceiceice> its copmiling right now but it fails one of the unit tests, the pathfinding one times out
20140614 17:14:59< iceiceice> it now takes like 20 seconds or something
20140614 17:15:06< iceiceice> im really not sure why it is slower now...
20140614 17:15:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 17:17:15-!- Haudegen [~quassel@178.115.128.160.wireless.dyn.drei.com] has quit [Ping timeout: 255 seconds]
20140614 17:17:43< mordante> are we talking about the pointers in unit and unit_animator
20140614 17:18:10< iceiceice> talking about the pointers that "own" the units
20140614 17:19:32< mordante> can you tell me in which classes/structs they are
20140614 17:19:40-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140614 17:19:50< mordante> I'm not too familiar with this area of the code and it's rather large
20140614 17:19:57< iceiceice> yeah... it has taken me a long time to learn
20140614 17:20:06< iceiceice> the unit_map can own units,
20140614 17:20:09< mordante> (unit is too large for its own good)
20140614 17:20:28< iceiceice> it has a struct "unit_pod"
20140614 17:20:28< iceiceice> used privately
20140614 17:20:28< iceiceice> which holds a reference count
20140614 17:20:38< iceiceice> and it deletes the unit when it's dead and there's no iterators to it (or something like this)
20140614 17:20:48< iceiceice> teams hold a std::vector<unit> which is the recall list
20140614 17:21:13< iceiceice> the unit_map normally "owns" the units, you insert a reference or a pointer, and it makes a private copy which it guarantees to delete,
20140614 17:21:17< iceiceice> unless the unit is "extracted"
20140614 17:21:20< iceiceice> then it gives away the pointer
20140614 17:21:24< iceiceice> without deleting
20140614 17:21:35< iceiceice> this can be given to lua
20140614 17:21:39< iceiceice> there is a wrapper lua_unit
20140614 17:21:47< iceiceice> which just holds a unit *
20140614 17:22:52< iceiceice> the other place that i know that units are owned are in the game_display object
20140614 17:24:08< mordante> and where in the animation engine is the pointer to the unit?
20140614 17:24:46< iceiceice> i think this is the segfaulting line: https://github.com/wesnoth/wesnoth/blob/master/src/unit_animation.cpp#L1374
20140614 17:24:50< iceiceice> if i remember correctly
20140614 17:25:27< iceiceice> i guess the pointer is here in the header: https://github.com/wesnoth/wesnoth/blob/master/src/unit_animation.hpp#L215
20140614 17:26:23< mordante> yes the pointer in the unit_animator class
20140614 17:28:24< iceiceice> ok i finished cachegrind, 
20140614 17:28:33< iceiceice> the reason my branch is slow is because i enabled the unit_map self checks i think
20140614 17:29:30< iceiceice> callgrind says that was 90% of the time :O
20140614 17:41:33< mordante> a quick scan of the code would assume the current code should be safe
20140614 17:41:45< mordante> is there a good recipe to reproduce the crash?
20140614 17:42:20< mordante> (btw I'm /not/ implying the code has a good design)
20140614 17:44:39< iceiceice> i think there are two bug reports
20140614 17:44:56< iceiceice> mattsc reports that if you go into debug mode,
20140614 17:45:09< iceiceice> and rapidly click to kill a unit,
20140614 17:45:09< iceiceice> the second kill operation will segfault
20140614 17:45:20< iceiceice> if it occurs during the animation of the first unit's death
20140614 17:45:24< mattsc> yes - it does.  
20140614 17:45:33< iceiceice> idk where the lua test case is
20140614 17:45:44< iceiceice> i think it's reported...
20140614 17:45:56< mattsc> It also works with the create unit dialog (and can be triggered in a couple other ways through :lua code), but the multi-kill is easiest to do
20140614 17:46:01< iceiceice> bug #21765
20140614 17:46:06< iceiceice> wesbot: bug #21765
20140614 17:46:07< wesbot> Bug #21765  Assigned to: None  Status: None  Priority: 5 - Normal
20140614 17:46:07< wesbot> Summary: segfault in animation code
20140614 17:46:07< wesbot> Original submission: Load the attached save and end turn; it should segfault. 
20140614 17:46:10< wesbot> If it doesn't, end turn a few more times. I've tested this in both 1.10.7 and 1.
20140614 17:46:11< mordante> mattsc, the second kill on the same unit?
20140614 17:46:13< wesbot> URL: http://gna.org/bugs/?21765
20140614 17:46:15< wesbot> Attached file (1st): http://gna.org/bugs/download.php?file_id=20273
20140614 17:46:24< iceiceice> wesbot: bug #21766
20140614 17:46:24< wesbot> iceiceice: Are you sure with that number?  Please check again...
20140614 17:46:26< mattsc> mordante: doesn’t matter.  Same unit or a different unit.
20140614 17:46:32< iceiceice> wesbot: bug #21768
20140614 17:46:32< wesbot> Bug #21768  Assigned to: None  Status: None  Priority: 5 - Normal
20140614 17:46:32< wesbot> Summary: segfault in lua_function= filter
20140614 17:46:33< wesbot> Original submission: Load the attached savefile and try to move the Wose from 
20140614 17:46:35< wesbot> (17,13) to (18,13).This ability filter lua_function= uses wesnoth.put_unit t
20140614 17:46:38< wesbot> URL: http://gna.org/bugs/?21768
20140614 17:55:23-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has joined #wesnoth-dev
20140614 17:56:25-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140614 17:57:23< iceiceice> yeah so heres my initial commit basically: https://github.com/cbeck88/wesnoth/commit/6a03594098c7fcd76564c9d216d8ec4591e2fc41
20140614 17:57:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 17:57:46< iceiceice> it doesnt fix the bug, its just a start to switch things over to use shared_ptr
20140614 17:57:55< iceiceice> but it is testing correctly it seems
20140614 17:58:08< iceiceice> and i didnt get any problems when i tried to play a campaign
20140614 17:58:25< iceiceice> theres still things i need to do to clean it up
20140614 18:01:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 18:01:41< mordante> the Lua case doesn't crash for me
20140614 18:02:20< mordante> I'm not sure that switching to a share_ptr is the best idea
20140614 18:02:48< mordante> we already have a reference counted pointer, to me it seems we misuse it in some places
20140614 18:03:10< iceiceice> what's our reference counter pointer?
20140614 18:04:20< iceiceice> the unit_map::iterator?
20140614 18:04:37< mordante> yes
20140614 18:05:42< iceiceice> yeah so what i would like to do is
20140614 18:05:51< iceiceice> refacotr that so that instead of using our own unit_pod reference counting implementation
20140614 18:05:59< iceiceice> we use the boost implementation
20140614 18:06:13< iceiceice> and then, use the reference countign mechanism throughout the program
20140614 18:06:18< iceiceice> right now its like, each module has it's own policy
20140614 18:06:24< iceiceice> the unit_map uses unit_pods
20140614 18:06:28< iceiceice> the whiteboard actually does use shared_ptr
20140614 18:06:35< iceiceice> for some private things,
20140614 18:06:41< mordante> I'm not sure whether shared_ptr are the best in this case
20140614 18:06:42< iceiceice> but it has to use auto_ptr to interface with other modules
20140614 18:06:53< mordante> they may have overhead since they are thread save
20140614 18:06:59< iceiceice> thats true
20140614 18:07:15< mordante> auto_ptr is like scoped_ptr having unique ownership
20140614 18:07:35< iceiceice> at the beginning of this i thought maybe the right thing is to start using unit_pod everywhere?
20140614 18:07:47< iceiceice> but thats sort of like writing a new smart pointer class
20140614 18:11:22< iceiceice> maybe we should do that i guess
20140614 18:11:38< iceiceice> so in most if not all of the commit i used a typedef UnitPtr for shared_ptr<unit>
20140614 18:11:49< iceiceice> but i guess it could be defined for some "non-threadsafe" shared_ptr version
20140614 18:11:58-!- Haudegen [~quassel@178.115.128.160.wireless.dyn.drei.com] has joined #wesnoth-dev
20140614 18:12:00< iceiceice> using the stuff we have in unit_pod right now
20140614 18:12:31< iceiceice> idk i didnt think about that
20140614 18:13:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 18:14:22< aquileia> mordante: https://github.com/wesnoth/wesnoth/pull/204
20140614 18:14:49< mordante> the unit_pod does the resource ref counting on its iterator
20140614 18:15:13< mordante> I'm not sure both crashes are the same 
20140614 18:15:37< mordante> EliDupree, has a segfault shift-k spamming results in an assertion failure
20140614 18:15:58-!- sachith500 [~kvirc@112.134.166.89] has quit [Read error: Connection reset by peer]
20140614 18:16:18-!- sachith500 [~kvirc@112.134.166.89] has joined #wesnoth-dev
20140614 18:16:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 18:17:18< iceiceice> yeah, right now the unit_pod only is manipulated by the iterator
20140614 18:17:21< iceiceice> but it could work differently
20140614 18:18:44-!- sachith500 [~kvirc@112.134.166.89] has quit [Read error: Connection reset by peer]
20140614 18:19:42< iceiceice> the way i see it, regardless of the bugs it would be worthwhile for the animation engine to be able to check if it's unit still exists
20140614 18:20:02< iceiceice> *regardless of the reported bugs
20140614 18:20:34< iceiceice> it's not possible for it to hold a unit_map::iterator instead of a unit *,
20140614 18:20:54< iceiceice> because it has to be able to animate like 5 different kinds of units, which aren't all in unit_maps
20140614 18:26:27-!- Sulfur [~Miranda@p5B008377.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]
20140614 18:29:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 18:34:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 18:38:11< mordante> I had another look I think the erase code is to blame
20140614 18:38:19-!- trewe [~trewe@2001:8a0:d12f:7e01:626c:66ff:fe92:9b7c] has joined #wesnoth-dev
20140614 18:38:29< mordante> it shouldn't erase a unit when there are still references to it
20140614 18:38:34-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 18:38:47< mordante> instead it should set a delete flag and delete it when all references are gone
20140614 18:39:05< mordante> the valid() test should then look at this flag
20140614 18:40:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 264 seconds]
20140614 18:40:54-!- aquileia_ [2edf50c1@gateway/web/freenode/ip.46.223.80.193] has joined #wesnoth-dev
20140614 18:41:37-!- aquileia [2edf50c1@gateway/web/freenode/ip.46.223.80.193] has quit [Ping timeout: 246 seconds]
20140614 18:41:53-!- Sulfur [~Miranda@p5B008377.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140614 18:48:25-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 18:53:33-!- prophile [~alynn@oftn/member/prophile] has quit [Quit: The Game]
20140614 18:53:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 18:54:41-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140614 18:54:43-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140614 18:55:11-!- Haudegen [~quassel@178.115.128.160.wireless.dyn.drei.com] has quit [Ping timeout: 244 seconds]
20140614 18:55:39< mordante> iceiceice, not sure whether the unit_animator needs to hold weak_ptrs I think it also needs to hold a shared_ptr
20140614 18:56:26< mordante> the animator has its own lifetime and the unit should remain valid in it and I don't see cycles there
20140614 18:56:55< gfgtdf> iceiceice: from the code it seems like we support a map= attribute at scenarios ? Do you know something about this ?
20140614 18:58:17< mordante> I still don't think switching to a share_ptr will save us here, or at least the unit_map code then needs to be rewritten
20140614 18:58:49< gfgtdf> wesbot: seen fabi
20140614 18:58:49< wesbot> gfgtdf: The person with the nick fabi last spoke 4d 3h ago.  3d 16h ago was here and on the channels #wesnoth, #wesnoth-de and #wesnoth-umc-dev with the message: Ping timeout: 240 seconds
20140614 18:59:32-!- trewe [~trewe@2001:8a0:d12f:7e01:626c:66ff:fe92:9b7c] has quit [Ping timeout: 260 seconds]
20140614 19:01:22-!- riksteri [~riksteri@dsl-tkubrasgw3-54f96b-216.dhcp.inet.fi] has quit [Quit: riksteri]
20140614 19:03:46-!- trewe [~trewe@178.50.54.77.rev.vodafone.pt] has joined #wesnoth-dev
20140614 19:03:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140614 19:05:11< iceiceice> mordante: maybe it would be better if we used boost::intrusive_ptr ?
20140614 19:05:56< iceiceice> as i understand, the idea there is that you add the reference counter as a member variable to the unit class
20140614 19:06:06< iceiceice> and add inline accessors to increment and decrement it,
20140614 19:06:09< iceiceice> http://baptiste-wicht.com/posts/2011/11/boost-intrusive_ptr.html
20140614 19:06:26< iceiceice> but if it let us factor out the unit_pod object it might be faster than the current implementation
20140614 19:07:17< iceiceice> mordante: yeah if we did any of these things then it would be my intention that the unit_map would be rewritten to accomodate
20140614 19:07:25< iceiceice> but unit_map::iterator would still work the same way
20140614 19:07:37< mordante> yes intrusive pointer has less allocations and you can decide whether or not it's thread safe
20140614 19:07:53< mordante> we already use the intrusive_ptr in some places
20140614 19:08:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 19:08:51< mordante> have a look at reference_counted_object.hpp
20140614 19:10:25< mordante> IMO the whole iterator's design is somewhat broken
20140614 19:10:48< iceiceice> yeah its sort of confused
20140614 19:10:56< iceiceice> its like the iterator that really wanted to be a smart pointer
20140614 19:10:56< mordante> the iterator shouldn't do the reference counting
20140614 19:11:13< iceiceice> it makes it somewhat annoying to use sometimes also
20140614 19:11:23< iceiceice> like, if the iterator could not run backwards,
20140614 19:11:33< iceiceice> you could return a non-const end() iterator
20140614 19:11:34< iceiceice> even from a const map
20140614 19:12:03< iceiceice> but as it is you can't do that, it made it somewhat annoying when i was refactoring in another case
20140614 19:12:31< iceiceice> i dont even know why we allow that, do we ever use the operator-- on the unit_map::iterators?
20140614 19:13:40< iceiceice> hmm so the idea of the reference counted object is to use inheritance/
20140614 19:13:55< mordante> will the interface supports it
20140614 19:14:18< mordante> is inheritance a problem?
20140614 19:14:41< iceiceice> no i guess not
20140614 19:14:52< iceiceice> is it slower?
20140614 19:14:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 264 seconds]
20140614 19:15:11< iceiceice> i guess it doesn't really matter
20140614 19:15:51< mordante> only that it adds a vtable to the object, probably a templated solution could be slightly faster
20140614 19:16:10< mordante> however I don't expect the slowdown to be huge
20140614 19:16:14< iceiceice> yeah
20140614 19:16:23< iceiceice> is it necessary to put a const_cast before the delete call?
20140614 19:16:32< iceiceice> i thought that you could delete even const pointers
20140614 19:18:07< mordante> I'm not 100% sure but I thought you indeed can
20140614 19:19:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 19:19:56< prophile> it appears you can
20140614 19:20:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20140614 19:21:37< mordante> well the code is old and at that time the developers used a compiler older than c++98
20140614 19:21:49< mordante> so it might be that compiler required the const_cast
20140614 19:23:09< mordante> aquileia_, I'll have to look at your pull later unless somebody beats me to it
20140614 19:23:13< mordante> I'm off bye
20140614 19:23:34< iceiceice> bye
20140614 19:23:37-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20140614 19:25:20-!- Octalot [~noct@132.53.125.91.dyn.plus.net] has joined #wesnoth-dev
20140614 19:28:10-!- aquileia_ [2edf50c1@gateway/web/freenode/ip.46.223.80.193] has quit [Ping timeout: 246 seconds]
20140614 19:35:41-!- irker485 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20140614 19:48:48< AI0867> 22:37 < iceiceice_> so unit_pod will go away ← one of the purposes of unit_pod is to make iterator invalidation impossibl
20140614 19:50:27-!- prophile [~alynn@oftn/member/prophile] has quit [Quit: The Game]
20140614 19:53:31-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140614 19:57:47< iceiceice> AI0867: yeah but if unit_pod holds an intrusive pointer instead of a raw pointer
20140614 19:57:55< iceiceice> then we can just get rid of the unit_pod
20140614 19:58:01< iceiceice> and ask the intrusive pointer if we are invalid
20140614 19:58:49< iceiceice> so the iterators would still work the same way,
20140614 19:58:57< iceiceice> its just that the reference counting system woudl be uniform across the engine
20140614 20:04:13< AI0867> 19:20 < mordante> (unit is too large for its own good) ← yes, a good refactor would be to take all the animation state and move it into a new object. (somehow, we already have a unit_animator class that doesn't do this?)
20140614 20:05:57-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140614 20:07:55-!- Kexoth [~kex@93-142-172-174.adsl.net.t-com.hr] has joined #wesnoth-dev
20140614 20:14:58-!- thunderstruck [~zaibotren@cpc7-cowc7-2-0-cust670.14-2.cable.virginm.net] has quit [Quit: leaving]
20140614 20:38:27-!- Octalot [~noct@132.53.125.91.dyn.plus.net] has quit []
20140614 20:40:04-!- Sulfur [~Miranda@p5B008377.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20140614 20:40:31-!- irker329 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20140614 20:40:31< irker329> wesnoth: Chris Beck wesnoth:master 85de1c2c55d6 / src/ (unit.cpp unit.hpp): remove unused portrait function from unit http://git.io/RlF8Ow
20140614 20:44:56-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140614 20:48:17-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20140614 20:48:33-!- cib_ [~cib@p5DD22616.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20140614 20:49:53-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20140614 21:12:53-!- _8680_ [~8680@2002:4404:712c:0:20e5:e19e:94f7:c5b7] has quit [Ping timeout: 264 seconds]
20140614 21:15:20-!- _8680_ [~8680@2002:4404:712c:0:80f6:3ca0:9bbf:b03e] has joined #wesnoth-dev
20140614 21:15:59-!- c74d [~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766] has quit [Excess Flood]
20140614 21:19:03< irker329> wesnoth: Chris Beck wesnoth:master 1796b4d7a0e6 / src/ (14 files in 3 dirs): remove unnecessary resources.hpp include from unit.hpp http://git.io/yC0nbg
20140614 21:20:07-!- c74d [~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766] has joined #wesnoth-dev
20140614 21:20:56-!- _8680_ [~8680@2002:4404:712c:0:80f6:3ca0:9bbf:b03e] has quit [Ping timeout: 260 seconds]
20140614 21:23:49-!- _8680_ [~8680@2002:4404:712c:0:c8e0:8f75:e197:745d] has joined #wesnoth-dev
20140614 21:28:23-!- _8680_ [~8680@2002:4404:712c:0:c8e0:8f75:e197:745d] has quit [Ping timeout: 272 seconds]
20140614 21:29:13-!- _8680_ [~8680@2002:4404:712c:0:fd1e:28fd:d998:cc47] has joined #wesnoth-dev
20140614 21:49:15-!- gfgtdf_ [~chatzilla@f054174070.adsl.alicedsl.de] has joined #wesnoth-dev
20140614 21:51:15-!- gfgtdf [~chatzilla@f054147096.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20140614 21:51:25-!- gfgtdf_ is now known as gfgtdf
20140614 22:02:06< gfgtdf> iceiceice: when replaying httt scenario 2 i get a segfault during a the prestart event during placing a unit.
20140614 22:02:39< iceiceice> hmm
20140614 22:02:51< iceiceice> it sounds the same as shadowms thing
20140614 22:03:17< iceiceice> do you know where the segfault is?
20140614 22:03:48< gfgtdf> iceiceice: http://pastebin.com/8LtRSUFk
20140614 22:05:06< gfgtdf> iceiceice: at first view it seems like the const std::vector<const shroud_map*>& maps parameter passed to shared_value is corrupt but msvc debuggng information in release builds is not 100% reliable
20140614 22:05:48< gfgtdf> iceiceice: what is shadowm thing ?
20140614 22:06:07< iceiceice> similar
20140614 22:06:14< iceiceice> he reported like yesterday
20140614 22:06:21< iceiceice> the commit i assume is invovled is this: https://github.com/wesnoth/wesnoth/commit/5145c9422c2dd26efd9f532f88f99730801c6019
20140614 22:14:31-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Remote host closed the connection]
20140614 22:16:16< gfgtdf> iceiceice: i think httt scenario 2 doesnt use fog/shroud for any side
20140614 22:16:40< iceiceice> i think its an initialization order problem
20140614 22:16:43< iceiceice> idk though
20140614 22:16:48< iceiceice> it would be good to confirm that its introduced in that commit
20140614 22:16:52< iceiceice> if its not then i have no idea whats going on
20140614 22:17:06< gfgtdf> ice
20140614 22:17:07< iceiceice> what do i have to do reproduce?
20140614 22:17:17< gfgtdf> iceiceice: hm i playyed httt scenario 2
20140614 22:17:22< gfgtdf> and then tried to replay
20140614 22:17:23< iceiceice> do you :cl to scenario 2?
20140614 22:17:39< gfgtdf> no i used my make easy mod
20140614 22:18:25< iceiceice> just make konrad really strong or smth?
20140614 22:18:32< gfgtdf> ye
20140614 22:19:43-!- Haudegen [~quassel@91.141.0.88.wireless.dyn.drei.com] has joined #wesnoth-dev
20140614 22:20:30< gfgtdf> iceiceice: here my replayfile that causes crashes for me: http://pastebin.com/x801WTpA
20140614 22:21:24< gfgtdf> iceiceice: i'ts not guaranteed to work you you thogh since i changed the savegame format a little, but i still think it should work
20140614 22:21:40< gfgtdf> iceiceice: it's from my featurebranch
20140614 22:23:04< gfgtdf> iceiceice: i just tested with an unknown earlier 1.13-dev version and it works there
20140614 22:23:21< gfgtdf> iceiceice: did you reproduce ?
20140614 22:23:28< iceiceice> i havnet tried yet im on another branch
20140614 22:23:47< gfgtdf> iceiceice: why not trying on that branch ?
20140614 22:25:17< iceiceice> because this branch doesnt compile
20140614 22:25:44< iceiceice> ill change give me a sec
20140614 22:32:22-!- Haudegen [~quassel@91.141.0.88.wireless.dyn.drei.com] has quit [Read error: Connection reset by peer]
20140614 22:37:45-!- mjs-de [~mjs-de@f048075239.adsl.alicedsl.de] has quit [Remote host closed the connection]
20140614 22:41:01< irker329> wesnoth: Chris Beck wesnoth:master a60d5b001843 / / (13 files in 5 dirs): move formula ai features of unit to a unit formula manager http://git.io/M3v8xg
20140614 22:42:38< iceiceice> gfgtdf: ok i got a segfault on your test file
20140614 22:43:12-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20140614 22:47:11< iceiceice> gfgtdf: i think i figured out a reason why it takes so damn long to compile
20140614 22:47:39< gfgtdf> iceiceice: so what do you thin is a reason ?
20140614 22:47:45< iceiceice> the reason is that, team.hpp includes unit.hpp
20140614 22:47:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140614 22:47:49< iceiceice> and display.hpp includes team.hpp
20140614 22:47:58< iceiceice> so practically every file is including all of unit.hpp
20140614 22:48:11< iceiceice> every play controller object, every part of editor,
20140614 22:48:20< iceiceice> has to include all of the like, formula ai primitives...
20140614 22:48:26< iceiceice> the unit animation primitives...
20140614 22:48:32< iceiceice> until very recently, the code to draw a portrait...
20140614 22:48:56< iceiceice> because a ton of objecst include the display
20140614 22:49:12< iceiceice> i worked today to cut down on the crap that is in unit,
20140614 22:49:28< iceiceice> it turned otu the portrait include wasnt even used by any code, it was just junking up the compile times
20140614 22:49:48< iceiceice> i pushed the formula ai stuff into a manager that unit just holds a poitner to
20140614 22:49:56< iceiceice> i think unit abilities should be handled similarly
20140614 22:50:54< iceiceice> i guess after my other branch is merged then team wont even need to include unit?
20140614 22:53:28< iceiceice> hmm maybe it will
20140614 22:53:43< iceiceice> i guess i should change htat
20140614 22:56:46< iceiceice> hmm i still segfault at the commit i referenced,
20140614 22:56:48< iceiceice> but its different somehow
20140614 22:58:14< iceiceice> http://hastebin.com/awabetixev.pas
20140614 22:58:23< irker329> wesnoth: mattsc wesnoth:master c837ee8d4207 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Update Xcode project http://git.io/ZVzBFQ
20140614 22:59:05< mattsc> wesbot: sometimes we are fast
20140614 22:59:44< iceiceice> heh that was pretty quick
20140614 23:00:13-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140614 23:00:56< mattsc> Well, it pinged me because there was an ‘ai’ in the line, so I checked out what it was all about and figured I’d take care of it right away before I forget.
20140614 23:01:31< mattsc> wesbot didn’t react to its own line though, that’s disappointing.
20140614 23:02:48< iceiceice> hehe
20140614 23:02:51< iceiceice> wesbot has gone AWOL
20140614 23:03:08< Aishiko> mordante the image.cpp hunk starting at 789 was totally not my doing, however I'll try and make it look better if you'd like.
20140614 23:04:47< iceiceice> gfgtdf: i guess my commit didnt introduce this
20140614 23:04:52< Aishiko> mordante the chunk with the while(), was one of the questions I had for you (ie what should I put in it to make it do what it needs to do)  happygrue figured pushing it out to get comments even if it didn't compile was needed.
20140614 23:06:04-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has quit [Quit: leaving]
20140614 23:06:43< Aishiko> mordante the reason for them being in different branches is that I didn't change over to the spritesheet branch as I had thought, and once I had it said that those commits where there already so I wasn't sure how to get to those commits in the spritesheet branch, but its been fixed and all will be sent via the spritesheet branch now
20140614 23:06:55< iceiceice> gfgtdf: i made a change here: https://github.com/wesnoth/wesnoth/commit/13fca9a35894047ae7da30cd3da516b94a0aca46 ?
20140614 23:06:57< iceiceice> idk if its responsible, will find out
20140614 23:07:53< iceiceice> gfgtdf: does your replay work on 1.12?
20140614 23:08:58< gfgtdf> iceiceice: i have a version 1.13-dev that i cmpiled on 11.6.2014 where my save didnt crash, but cannot tell from which commit that is, (and ofc "undefined debahiour" deoesn't imply "crash")
20140614 23:09:13-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140614 23:09:21< gfgtdf> iceiceice: i can test on 1.12 too
20140614 23:09:41< iceiceice> i cant do that atm because im compiling on 1.13
20140614 23:09:54< iceiceice> i dont know of any "good" commits right now 
20140614 23:09:59< iceiceice> wrt this test
20140614 23:11:09< gfgtdf> iceiceice: on 1.11.13 it worked
20140614 23:11:18< iceiceice> ok thx
20140614 23:13:32-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 245 seconds]
20140614 23:15:50< iceiceice> ok this commit is also good
20140614 23:15:50< iceiceice> 5dad318849fd1411b9c226c029c5ec5a389c8cb2
20140614 23:15:53< iceiceice> so its from the last 4 days
20140614 23:18:40< iceiceice> gfgtdf: do you see anything bad in this commit? https://github.com/wesnoth/wesnoth/commit/13fca9a35894047ae7da30cd3da516b94a0aca46#diff-be5307f4f80f2fd94e3828bcee8bb052R240
20140614 23:20:02< gfgtdf> iceiceice: no, but i also dont relay know about th eintitilisation order in playcontroller cpp
20140614 23:20:34< gfgtdf> iceiceice: i think we maybe shoudl put less logic in the contructor and maybe call init or related manually
20140614 23:20:42< gfgtdf> but idk
20140614 23:20:49< iceiceice> i think either it should all be constructor or all be init
20140614 23:22:11< gfgtdf> hmm mbye forget what i said
20140614 23:22:36< iceiceice> gfgtdf: do you know why the replay.cpp includes game_display.hpp?
20140614 23:23:45< iceiceice> idk there should be less includes in there
20140614 23:23:47< gfgtdf> iceiceice: hm maybe for teh "resources::screen->add_chat_message()" cakls
20140614 23:23:52< gfgtdf> calls
20140614 23:23:53-!- trademark_ [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has quit [Ping timeout: 264 seconds]
20140614 23:24:32< gfgtdf> iceiceice: ye i think we definitely can remove come of them
20140614 23:24:42< gfgtdf> iceiceice:  for example i think we can rmeove the actions/ includes
20140614 23:25:16< iceiceice> hmm
20140614 23:25:22< iceiceice> i have no idea what commit made this segfault
20140614 23:26:52< gfgtdf> me neigher 
20140614 23:26:58< iceiceice> im trying this one now
20140614 23:26:58< iceiceice> https://github.com/wesnoth/wesnoth/commit/a16ed4ccfd9393d17f2e5d705de22f6b667a335c
20140614 23:28:41< gfgtdf> iceiceice: maybe we shoudl have a bisect server :p
20140614 23:29:12< iceiceice> hehe
20140614 23:29:18< iceiceice> thats not a bad idea
20140614 23:30:05< gfgtdf> bbl
20140614 23:30:14-!- gfgtdf [~chatzilla@f054174070.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 29.0.1/20140506152807]]
20140614 23:48:23< Coffee_irc> ping iceiceice
20140614 23:48:27< iceiceice> hi
20140614 23:48:31< Coffee_irc> hi
20140614 23:48:50< Coffee_irc> do you remember working on the get_relative_direction map thingy?
20140614 23:49:04< iceiceice> yeah
20140614 23:49:13< Coffee_irc> I had a look at the current master code
20140614 23:49:20< Coffee_irc> currently it uses your code
20140614 23:49:38< Coffee_irc> but it doesn't produce a nice test image
20140614 23:50:18< Coffee_irc> is this something you are still owrking on?
20140614 23:50:21< iceiceice> yeah i think the test image thing is off by one
20140614 23:50:21< Coffee_irc> *working
20140614 23:50:27< iceiceice> so theres a better test scenario
20140614 23:50:31< Coffee_irc> well...
20140614 23:50:34< iceiceice> im trying to remember how to laod it
20140614 23:50:35< Coffee_irc> my code works fine
20140614 23:51:00< iceiceice> coffee: so actually,
20140614 23:51:13< iceiceice> i set the other to be the default because it makes unit animations look really wierd if that one is the default
20140614 23:51:18< Coffee_irc> iceiceice: the way I loaded it for teting was to include the code in the main game_loop
20140614 23:51:24< iceiceice> yea but
20140614 23:51:35< iceiceice> there was some kidn of off by one error int he way that the code generates a map
20140614 23:51:43< Coffee_irc> ?
20140614 23:51:46< iceiceice> i reemmber you asked when i started, does it have to be with border ?
20140614 23:51:53< iceiceice> i think i said "i dont think so" but i think you were actually right
20140614 23:51:57< Coffee_irc> no it shouldn't
20140614 23:52:02< iceiceice> hmm so
20140614 23:52:09< iceiceice> i made a second test scenario
20140614 23:52:13< iceiceice> that actually runs in game
20140614 23:52:17< iceiceice> i made get_relative_dir have a wml tag
20140614 23:52:26< iceiceice> and it actually plots it as you move around
20140614 23:52:40< Coffee_irc> that is a good idea
20140614 23:52:41< iceiceice> and that one seems to disagree with the test we were originally using
20140614 23:52:53< Coffee_irc> doh
20140614 23:53:01< Coffee_irc> could be a translation issue though
20140614 23:53:11< Coffee_irc> 0,0 to 1,1 for top left corner
20140614 23:53:34< iceiceice> yeah i think its something like that idk
20140614 23:53:39< iceiceice> so if you want to test in the new way,
20140614 23:53:43< iceiceice> its like "wesnoth -t test_relative_dir
20140614 23:54:11< Coffee_irc> I'll give it a shot once I compile current master
20140614 23:54:28< iceiceice> ok
20140614 23:54:36< iceiceice> so that one is a bit different from the old one,
20140614 23:54:41< iceiceice> it uses labels to show the directions,
20140614 23:54:48< iceiceice> and it uses the terrain to test the rotation function
20140614 23:54:58< iceiceice> i guess you'll figure out if you play iwth it
20140614 23:55:10< Coffee_irc> yeah
--- Log closed Sun Jun 15 00:00:12 2014