--- Log opened Thu Jun 29 00:00:18 2017
20170629 00:22:26< shadowm> Overloading operator< isn't all that convenient when you need a different comparator for a very specific case.
20170629 00:24:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 00:28:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170629 00:31:09-!- yaiyan_ is now known as Ieuan
20170629 01:01:11-!- DeFender [~DeFender1@89-138-160-34.bb.netvision.net.il] has joined #wesnoth-dev
20170629 01:03:00-!- DeFender1031 [~DeFender1@89-138-182-62.bb.netvision.net.il] has quit [Ping timeout: 258 seconds]
20170629 01:35:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170629 01:37:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170629 01:52:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170629 01:52:42-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170629 01:53:07< pydsigner> Also, correct me if I'm wrong, but overloading operator< for sorting purposes seems like an anti-pattern unless it will also be useful for regular a-b comparisons.
20170629 02:04:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170629 02:49:36< vultraz_iOS> HHHHHHHHHHHHHHHHHHHHHHHHMMMMMMMMMMMMMM
20170629 02:49:57< vultraz_iOS> I wonder if GUI2 needs access to the drawing queue
20170629 02:50:23< vultraz_iOS> it already has a rather effective draw layering system
20170629 02:52:34< vultraz_iOS> probably should though...
20170629 02:53:33< vultraz_iOS> there's the problem where drawing order is essentially the same as event handler execution order
20170629 02:54:01< vultraz_iOS> yo celticminstrel maybe you can suggest a solution here
20170629 02:54:33< celticminstrel> I don't even know what you're talking about.
20170629 02:54:43< vultraz_iOS> hang on I'm typing the problem
20170629 02:54:50< vultraz_iOS> :P
20170629 02:56:11< vultraz_iOS> So with the "current" code, opening a new GUI2 dialog (ie, no dispatcher exists) adds a new handler to the current event context - in this case main. That means functionally, a UI handler is always on top of the handlers list and so its DRAW handler is called last, meaning the UI is drawn over the map
20170629 02:57:29< vultraz_iOS> But let's say we want the in-game UI to be floating modeless dialogs that are shown when game_display is created. This puts them, for some reason, *under* another context, meaning they're drawn under the map.
20170629 02:58:38< celticminstrel> So don't put them under another context, I guess?
20170629 02:58:40< vultraz_iOS> So my hacky solution locally here is to have the UI join the event context once, but execute the context backwards in events::pump()
20170629 02:58:57< vultraz_iOS> er, I meant to say "under another handler" above
20170629 02:59:04< celticminstrel> So don't do that?
20170629 02:59:07< vultraz_iOS> execute the context handler's backwards
20170629 03:01:44< vultraz_iOS> celticminstrel: so, I'm wondering, do we indeed always want the UI's events executed last?
20170629 03:02:32< celticminstrel> I feel like you'd want the UI to receive events before the map.
20170629 03:03:14< vultraz_iOS> hmmm
20170629 03:04:05< vultraz_iOS> right now the UI events are done last and the map events exited early if in-dialog
20170629 03:06:12< vultraz_iOS> celticminstrel: honestly, I think it might make sense to keep the current "only add handler when dialog open" method..
20170629 03:06:26< vultraz_iOS> but that doesn't solve the modeless dialog UI problem
20170629 03:06:35< vultraz_iOS> because then a dialog is open in perpetuity 
20170629 03:07:59< vultraz_iOS> which makes it seem like more sense to only join the event context once
20170629 03:08:58< vultraz_iOS> you aren't really helping :(
20170629 03:09:28< celticminstrel> Sorry.
20170629 03:10:27< celticminstrel> I do think the UI should probably process events before the map, though.
20170629 03:10:38< celticminstrel> Especially if there is theoretically part of the map hidden by the UI.
20170629 03:10:58< celticminstrel> ie, if the map technically covers the entire window and the UI is overlaid over that.
20170629 03:11:19< celticminstrel> If the map receives events first, clicks on the UI will instead pass through to the map, right?
20170629 03:11:19< vultraz_iOS> well it doesn't cover the whole window 
20170629 03:11:30< celticminstrel> It did in that sample you showed, though.
20170629 03:11:38< celticminstrel> With the ugly semi-transparent status bar,
20170629 03:11:54< vultraz_iOS> but yes, you have something like that happening...
20170629 03:11:54< celticminstrel> Or, at least, it overlapped with the UI, which is close enough.
20170629 03:12:25< celticminstrel> TBH if you're doing it that way it's probably simplest to just plaster the map across the whole window and then add the UI on top.
20170629 03:15:00< vultraz_iOS> hmmm
20170629 03:15:05< vultraz_iOS> Well...
20170629 03:15:34< vultraz_iOS> right now there's no clear distinction of which area we want to do what
20170629 03:15:35< vultraz_iOS> for example
20170629 03:15:47< vultraz_iOS> modal dialogs should block other events, but not draw events.
20170629 03:16:24< vultraz_iOS> modeless dialogs should not block other (ie map) events
20170629 03:16:41< vultraz_iOS> except if they're focused
20170629 03:18:08< vultraz_iOS> celticminstrel: does that seem right
20170629 03:22:58< vultraz_iOS> in which case...
20170629 03:23:46< vultraz_iOS> disregarding DRAW events for now, let's see...
20170629 03:29:16< vultraz_iOS> for modal dialogs it sounds like I'd need some way to "halt" events :/
20170629 03:29:23< vultraz_iOS> since we want DRAW events to occur...
20170629 03:29:30< vultraz_iOS> for modeless dialogs...
20170629 03:29:32< vultraz_iOS> I have no idea
20170629 03:29:59-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Read error: Connection reset by peer]
20170629 03:31:40-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170629 03:34:03< celticminstrel> vultraz_iOS: It doesn't quite sound right.
20170629 03:34:28< celticminstrel> The modeless dialog should get events before the map in two particular situations:
20170629 03:34:56< celticminstrel> 1) Keyboard events, when the modeless dialog or a child widget has the keyboard focus (or is in the keyboard chain).
20170629 03:35:13< celticminstrel> 2) Mouse or touch events which take place within the dialog's bounds.
20170629 03:35:38< vultraz_iOS> right, but I can't really figure out how to do that right
20170629 03:36:40< celticminstrel> Seems like it should be fine to just give the modeless dialog first chance at the event.
20170629 03:37:17< vultraz_iOS> I have a feeling you don't fully understand the event handler model
20170629 03:38:36< celticminstrel> That might be for the better though.
20170629 03:38:44< vultraz_iOS> all the event handlers are executed 
20170629 03:39:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 03:40:13< vultraz_iOS> it's up to the handlers to handle specific events
20170629 03:41:40< vultraz_iOS> events::pump iterates over the events list
20170629 03:42:27< vultraz_iOS> on each iteration, every handler is called with the specific event
20170629 03:43:40< vultraz_iOS> it's up to the handlers to dispatch them as appropriate
20170629 03:44:39< vultraz_iOS> so let's say the handler list looks like this: UI -> Map (just a simplification)
20170629 03:44:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20170629 03:44:51< vultraz_iOS> and we're iterating through the event queue
20170629 03:44:58< vultraz_iOS> and we hit a keyboard event
20170629 03:46:19< vultraz_iOS> the loop might perform some of its own handling, but then you have this
20170629 03:46:36< vultraz_iOS> ui handler gets sent the keyboard event to handle as it wants
20170629 03:46:42< vultraz_iOS> map handler gets sent the keyboard event
20170629 03:47:21< vultraz_iOS> and then on to the next event
20170629 03:47:25< vultraz_iOS> let's say it a click event
20170629 03:47:27< vultraz_iOS> same thing happens
20170629 03:47:35< vultraz_iOS> UI handler gets it
20170629 03:47:39< vultraz_iOS> then map handler gets it
20170629 03:49:25< vultraz_iOS> hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
20170629 03:50:39< celticminstrel> What about piping everything through the GUI2 event system then?
20170629 03:50:58< vultraz_iOS> eh?
20170629 03:50:59< vultraz_iOS> no
20170629 03:51:02< vultraz_iOS> can't do that
20170629 03:51:06< celticminstrel> Why not?
20170629 03:51:22< vultraz_iOS> it would have to be made global
20170629 03:51:35< vultraz_iOS> and I'm not sure I can do that
20170629 03:52:52< vultraz_iOS> I'd need to expand the concept of the dispatcher to other areas of the game 
20170629 03:54:19< vultraz_iOS> I mean, it could be done
20170629 03:54:23< vultraz_iOS> but it wouldn't be simple
20170629 03:55:40< vultraz_iOS> celticminstrel: how would that help?
20170629 03:55:57< vultraz_iOS> right now I'm thinking of adding some way to... halt events 
20170629 03:56:13< vultraz_iOS> ie, break the handler loop for a specific event
20170629 03:56:15< vultraz_iOS> so like
20170629 03:56:44< vultraz_iOS> say the UI can just return false for an event if it wants the handling to stop there
20170629 03:57:06< celticminstrel> Well, I think you just answered your own question?
20170629 03:57:57< vultraz_iOS> yes, you are a useful rubber duck 
20170629 03:58:09< vultraz_iOS> but there's stil a problem
20170629 03:58:25< vultraz_iOS> how to know when to halt
20170629 03:58:36< vultraz_iOS> because remember, the UI handler is always in the queue
20170629 03:59:25< celticminstrel> I guess you would halt if it was a mouse event with coordinates in the window's bounds?
20170629 03:59:36-!- Kwandulin [~Kwandulin@p200300760F2142D5054F6F0D9B82BCF5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170629 03:59:55< celticminstrel> If you're using GUI2 event handling you'll need a distributor BTW.
20170629 04:00:18< celticminstrel> I think the window widget does have one built in, might be sufficient, might not.
20170629 04:01:50< vultraz_iOS> it does
20170629 04:02:13< vultraz_iOS> have one, that is
20170629 04:03:55< vultraz_iOS> but I don't know if I want to expand the UI system to everything
20170629 04:03:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 04:06:38< vultraz_iOS> wait..
20170629 04:06:39< vultraz_iOS> hm..
20170629 04:06:47< vultraz_iOS> celticminstrel: for modal dialogs we want to stop all events right?
20170629 04:07:14< vultraz_iOS> besides DRAW
20170629 04:07:55< celticminstrel> Draw probably shouldn't really be an event TBH, but... yeah, generally modal dialogs block all events.
20170629 04:08:08< celticminstrel> But drawing still needs to happen.
20170629 04:08:25< vultraz_iOS> how the hell else would drawing happen :/
20170629 04:08:34< celticminstrel> ...
20170629 04:08:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20170629 04:08:55< vultraz_iOS> well actually there is the draw() event..
20170629 04:09:06< celticminstrel> Admittedly there are events for drawing in several GUI frameworks though...
20170629 04:10:05< vultraz_iOS> celticminstrel: well, ok, say it wasn't an event... would we instead just call drawing functions every n ms from the timer?
20170629 04:10:34< celticminstrel> ...no. Absolutely not.
20170629 04:10:44< vultraz_iOS> then what!
20170629 04:10:47< celticminstrel> If you're handling rendering that way, you don't use a timer.
20170629 04:10:53< vultraz_iOS> I...
20170629 04:10:55< celticminstrel> Just call it every time through the loop.
20170629 04:11:02< vultraz_iOS> ok you'll need to explain more
20170629 04:11:10< celticminstrel> By "loop" I mean the event loop.
20170629 04:11:18< vultraz_iOS> ahhhhhh
20170629 04:11:29< vultraz_iOS> so events::pump
20170629 04:11:40< vultraz_iOS> after all the events are handled, go through and call all the handler's draw functions?
20170629 04:11:44< vultraz_iOS> is that what you're saying
20170629 04:13:36< vultraz_iOS> *pokes celticminstrel*
20170629 04:14:23< celticminstrel> That's the typical strategy, yeah.
20170629 04:14:30< vultraz_iOS> I see
20170629 04:14:38< vultraz_iOS> this is not a bad idea
20170629 04:14:47< celticminstrel> I mean, I guess it works as an event, but I find it weird.
20170629 04:15:13< vultraz_iOS> honestly it doesn't need to be
20170629 04:17:06< vultraz_iOS> I'm not 100% sure why it was
20170629 04:17:38< vultraz_iOS> if i decouple it it makes it easier, actually
20170629 04:17:50< vultraz_iOS> since then I can handle draw events separately 
20170629 04:18:14< celticminstrel> Though, would that break the places where dialogs hook into draw events?
20170629 04:19:02< vultraz_iOS> No
20170629 04:19:35< vultraz_iOS> in GUI2, the DRAW event calls the draw() function which fires all the draw event handlers
20170629 04:19:45< vultraz_iOS> the only difference would be calling draw() directly
20170629 04:19:47< vultraz_iOS> so, no change.
20170629 04:34:04-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 258 seconds]
20170629 04:35:18-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20170629 04:46:11< vultraz_iOS> celticminstrel: ok, so this is progress. Let's say we decouple events, then block further event execution if we have a modal dialog open
20170629 04:46:18< vultraz_iOS> what about modeless ones
20170629 04:49:17< celticminstrel> Events should just be distributed to all modeless windows.
20170629 04:49:32< celticminstrel> If none of them handle it, try passing the event to the map.
20170629 04:49:35< celticminstrel> Something like that.
20170629 04:49:51< vultraz_iOS> blah
20170629 04:49:51< celticminstrel> Mainly they only need to handle mouse and keyboard events.
20170629 04:49:56< vultraz_iOS> complicated
20170629 04:49:58< vultraz_iOS> very complicated
20170629 04:50:06< celticminstrel> (And touch and controller events, I guess.)
20170629 04:50:14< vultraz_iOS> so very complicated
20170629 04:53:31< celticminstrel> Yup.
20170629 04:53:34< celticminstrel> Good night.
20170629 04:54:11-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170629 05:07:58-!- Kwandulin [~Kwandulin@p200300760F2142D5054F6F0D9B82BCF5.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170629 06:21:09-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170629 06:42:14-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170629 06:52:21-!- JyrkiVesterinen [~JyrkiVest@85-76-74-69-nat.elisa-mobile.fi] has joined #wesnoth-dev
20170629 06:53:19< JyrkiVesterinen> loonycyborg: custom map comparators aren't redundant.
20170629 06:53:41< JyrkiVesterinen> It's a common situation that you want to store something in a map, but the key type doesn't have any natural order.
20170629 06:53:50< JyrkiVesterinen> Say, if you have a map from map locations to units.
20170629 06:54:02< JyrkiVesterinen> Implementing operator< doesn't make sense in such a situation.
20170629 06:54:50< loonycyborg> I was mostly joking
20170629 06:54:54< loonycyborg> though
20170629 06:55:03< loonycyborg> you can always make a wrapper type
20170629 06:55:28< JyrkiVesterinen> I'd still prefer to use a custom comparator instead.
20170629 06:55:38< loonycyborg> Yup it's nice
20170629 07:01:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 07:06:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20170629 08:49:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 08:54:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170629 08:54:48-!- Duthlet [~Duthlet@dslb-178-012-099-028.178.012.pools.vodafone-ip.de] has joined #wesnoth-dev
20170629 08:57:08-!- JyrkiVesterinen [~JyrkiVest@85-76-74-69-nat.elisa-mobile.fi] has quit [Quit: .]
20170629 09:19:50-!- sevu [~Shiki@p57803acb.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170629 09:26:26-!- JyrkiVesterinen [~JyrkiVest@85-76-74-69-nat.elisa-mobile.fi] has joined #wesnoth-dev
20170629 09:49:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 09:53:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20170629 10:04:52-!- sevu [~Shiki@p57803acb.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20170629 10:12:31-!- louis94 [~~louis94@109.131.102.51] has joined #wesnoth-dev
20170629 10:34:52-!- louis94 [~~louis94@109.131.102.51] has quit [Quit: Konversation terminated!]
20170629 11:01:32< vultraz_iOS> zookeeper: i assume you would object to breaking every image path in UMC referring to core images directly :P
20170629 11:11:25< zookeeper> ò.Ó elaborate, please
20170629 11:12:01< vultraz_iOS> It appears spritesheets will improve performance.
20170629 11:12:13< vultraz_iOS> Spritesheets mean images will no longer be singular 
20170629 11:13:28< zookeeper> you can freely implement spritesheet support without having to worry about what exactly we'd be going to core unit animations, as those are two separate things.
20170629 11:15:45< vultraz_iOS> what??
20170629 11:15:51< vultraz_iOS> that sentence makes no sense
20170629 11:15:58< zookeeper> Ravana_, so does the AI now actually remember the previous visible location of an invisible unit?
20170629 11:16:10< Ravana_> no idea
20170629 11:16:22< Ravana_> but some weeks ago I said it would be good to have it remember it
20170629 11:16:37< zookeeper> well your post does say it now remembers them
20170629 11:17:38< vultraz_iOS> zookeeper: are you implying I would implement spritesheets but NOT convert core unit animations?
20170629 11:18:22-!- Duthlet [~Duthlet@dslb-178-012-099-028.178.012.pools.vodafone-ip.de] has quit [Ping timeout: 246 seconds]
20170629 11:18:27< zookeeper> vultraz_iOS, yes, of course. you shouldn't implement the feature and the next day convert all core unit animations in a way that breaks everything.
20170629 11:18:50< vultraz_iOS> Then I'll leave it to you to maintain two copies of every image :3
20170629 11:19:16< zookeeper> there's not even a need to break anything immediately, spritesheets can be added alongside the old images while we figure out what exactly to do
20170629 11:20:10< DeFender> can't a spritesheet be dynamically generated?
20170629 11:20:13< zookeeper> i'm not even saying we need to keep the old images around forever or anything like that, only that you shouldn't conflate implementing the feature and deciding how to handle backwards compatibility (or not).
20170629 11:20:25< vultraz_iOS> DeFender: all spritesheets have already been generated for Wesnoth 2
20170629 11:20:37< DeFender> vultraz_iOS, that's not what I meant.
20170629 11:20:46< vultraz_iOS> some are old and will have to be regenerated tho
20170629 11:21:04< zookeeper> vultraz_iOS, are you asking because you're going to get side-tracked into implementing spritesheets now?
20170629 11:21:26< vultraz_iOS> well I have been informed that it is more efficient and performance friendly to use spritesheets
20170629 11:21:27< DeFender> I meant that the configs still use the single images, but the engine looks at animations and generates spritesheets fro the single images when it loads.
20170629 11:22:05< vultraz_iOS> it...could be done
20170629 11:22:08< zookeeper> vultraz_iOS, everyone knows that. why are you telling me that and how is it relevant?
20170629 11:22:46< vultraz_iOS> relevant to maximizing performance on a_r
20170629 11:23:15< zookeeper> don't mix spritesheets in with a_r
20170629 11:23:24< zookeeper> don't mix animated fog in with a_r
20170629 11:23:35< zookeeper> don't try to make wesnoth 3d in a_r
20170629 11:24:44< DeFender> scope creep...
20170629 11:25:06< zookeeper> if you can actually conclude that yes, assets need to be structured differently in order to reach 1.12-level performance with a_r then _that_ would be different, but i rather doubt that's the case.
20170629 11:25:22< DeFender> avoid scope creep.
20170629 11:25:28< DeFender> scope creep is bad.
20170629 11:25:31< vultraz_iOS> well I still don't know what's causing 100% CPU
20170629 11:25:31< JyrkiVesterinen> I think generating spritesheets at runtime is indeed a good idea.
20170629 11:25:58< DeFender> vultraz_iOS, then shooting in the dark seems like a bad idea.
20170629 11:26:27< zookeeper> yes, "i don't know what's causing 100% CPU" -> "i'm gonna implement spritesheets" doesn't make any sense
20170629 11:26:46< vultraz_iOS> If I do dynamically generated spritesheets I could probably do it a lot easier than converting everything to sheets natively
20170629 11:27:49< zookeeper> and yeah, "spritesheets" can mean either dynamically-generated ones which exist only for internal performance reasons, or it can mean having the assets in sheets which can additionally be more comfortable for artists, take up less disk space, etc.
20170629 11:28:19< JyrkiVesterinen> It was me who suggested spritesheets.
20170629 11:28:40< vultraz_iOS> There are multiple ways I could do dynamically generated spritesheets...
20170629 11:28:40< JyrkiVesterinen> The reason for that is that the number of render passes should be kept low enough.
20170629 11:29:49< JyrkiVesterinen> I have told vultraz in Discord earlier that I recommend outright rewriting the rendering code instead of refactoring existing code, because the requirements for software and hardware rendering are completely different.
20170629 11:30:08< zookeeper> maybe the ideal solution, which of course might be very difficult, would be to have dynamically generated spritesheets at first, but to have that system be compatible enough with drawn spritesheets that the latter is easy to add later.
20170629 11:30:23< vultraz_iOS> Perhaps
20170629 11:31:17< zookeeper> JyrkiVesterinen, yeah, having the game compile the frames into sheets makes a lot of sense for accelerated rendering
20170629 11:31:49< vultraz_iOS> The hard part is getting the appropriate images to load...
20170629 11:32:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 11:33:00< zookeeper> the question of whether it should be an internal thing only, or whether it should involve an asset conversion, or a bit of both, and what the spritesheet API/specs should be like if support for drawn spritesheets is added... are all a bit different questions
20170629 11:34:35< vultraz_iOS> well, if we do asset conversion I'm definitely looking to Wesnoth 2 for reference
20170629 11:35:01< vultraz_iOS> and using anura to generate them.
20170629 11:35:12< vultraz_iOS> no way in hell I'm putting them together manually
20170629 11:35:14< zookeeper> i'd posit that _maybe_ one possibility for a sane logic for the internal spritesheet compilation would be to do it per-directory; just start dumping images from the same directory into the same sheet, and of course split them off into whatever size textures are convenient when the first one is full.
20170629 11:36:14< vultraz_iOS> That is... uh...
20170629 11:36:21< zookeeper> it's possible that could result in a lot of wasted video memory though
20170629 11:36:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170629 11:37:41< DeFender> zookeeper, it also doesn't account for IPFs.
20170629 11:38:05< DeFender> which is why I think dynamic generation at runtime is the way to go.
20170629 11:38:06< vultraz_iOS> a million curses upon IPFs
20170629 11:38:21< DeFender> umm... no. IPFs are wonderful.
20170629 11:38:21< zookeeper> ah, true. well... just have a separate special sheet for IPFs? i mean you can still compile sheets on demand
20170629 11:38:39< vultraz_iOS> anyway these are the sheets I'll probably try to emulate 
20170629 11:38:40< vultraz_iOS> https://github.com/anura-engine/wesnoth2/tree/master/images/terrain
20170629 11:38:40< zookeeper> just have all IPF images go into a separate sheet
20170629 11:38:50< vultraz_iOS> and https://github.com/anura-engine/wesnoth2/tree/master/images/units
20170629 11:39:19< zookeeper> what sheets are you talking about now?
20170629 11:39:20< zookeeper> which kind?
20170629 11:39:30< vultraz_iOS> what?
20170629 11:39:48< zookeeper> because those terrain sheets are completely unusable for actual assets
20170629 11:39:55< vultraz_iOS> uhhh...
20170629 11:39:56< zookeeper> the unit sheets are fine because they have borders
20170629 11:40:13< vultraz_iOS> well that's why this exists
20170629 11:40:14< vultraz_iOS> https://github.com/anura-engine/wesnoth2/blob/master/data/terrain-file-data.cfg
20170629 11:40:29< vultraz_iOS> M A G I C N U M B E R S
20170629 11:40:42< zookeeper> don't even try to make me try to work with terrain graphics through some kind of magic numbers hack file like that
20170629 11:41:03< vultraz_iOS> no the terrain graphics are here
20170629 11:41:04< vultraz_iOS> https://raw.githubusercontent.com/anura-engine/wesnoth2/master/data/terrain-graphics.cfg
20170629 11:41:37< vultraz_iOS> also the file is probably generated by a tool
20170629 11:41:53< zookeeper> yeah, just don't do that. that's insanity.
20170629 11:42:00< vultraz_iOS> use a tool?
20170629 11:42:04< vultraz_iOS> what's wrong with tools
20170629 11:43:01< zookeeper> no, don't ever try to convert our assets into those kinds of terrain sheets, because that makes it 3x more work to ever do any meaningful work on them.
20170629 11:43:35< vultraz_iOS> why
20170629 11:44:01< vultraz_iOS> though I suppose for a tool you'd still need the individual images....
20170629 11:45:43< zookeeper> because you'd have to first decompile the sheet, then edit the images which would now be at completely inconsistent sizes and offsetted wrong, making certain important things like being able to check for offsets and tiling and whatnot impossible, and then recompile the sheet when you're done and hope that nothing went wrong because things are no longer WYSIWYG
20170629 11:46:23< vultraz_iOS> what I was thinking now based on DeFender's suggestion is one internal sheet per image prefix
20170629 11:46:24< zookeeper> maybe the middle part wouldn't be a problem since the decompilation step would presumably be able to restore the original size
20170629 11:46:40< zookeeper> (and yeah actually it'd have to)
20170629 11:48:33< vultraz_iOS> i honestly have no idea how the engine deals with the tg code internally
20170629 11:48:45< zookeeper> you can't assume that it's a good idea because that's how it is in wesnoth2, because no one has actually had to work with those yet. you have no idea how debilitatingly annoying the process could be.
20170629 11:48:48< vultraz_iOS> krista basicaly redesigned the whole thing in...two weeks or so
20170629 11:50:25< zookeeper> all that terrain stuff in wesnoth2 is just existing wesnoth stuff converted with a tool. now if i show you a screenshot where a certain kind of bridge connection has a little glitch, looking into it and fixing it is going to be a lot more cumbersome than with single images, or an artist-friendly sheet system.
20170629 11:50:55< vultraz_iOS> Last i checked there were no glitches 
20170629 11:51:00< zookeeper> ...
20170629 11:51:12< vultraz_iOS> BESIDES THE POINT I KNOW
20170629 11:51:15< vultraz_iOS> but just saying
20170629 11:51:21< vultraz_iOS> krista is a very good coder :|
20170629 11:51:37< Rhonda> #worksforme
20170629 11:52:31< vultraz_iOS> she was like, "oh, the anura hex map code needs a rewrite? ok sure here's it done in like 2 weeks"
20170629 11:52:31< zookeeper> this has nothing to do with good codership. i'm sure it's a very good system for internal performance improvement, and if you duplicate that _as an internal dynamically-generated spritesheet thing_ then that's great. but don't bring that to the actual assets.
20170629 11:58:19< zookeeper> there's a world of convenience difference between "each image is a separate image, you can just edit them and add new ones" and... 
20170629 11:58:21< zookeeper> https://github.com/anura-engine/wesnoth2/blob/master/images/terrain/bridge.png has the images, then https://github.com/anura-engine/wesnoth2/blob/master/data/terrain-file-data.cfg has coordinate data, then you need some custom command-line tool to convert a sheet into single images and back again and it's all really complicated and driven by magic numbers
20170629 12:01:47< DeFender> agreed.
20170629 12:02:07< vultraz_iOS> well i can't argue with that
20170629 12:02:22< vultraz_iOS> but sometimes obvious simplicity isn't the best 
20170629 12:02:31< vultraz_iOS> probably is in this case though
20170629 12:02:47< zookeeper> especially as far as terrains go, you should note that if you can do about half of all the other stuff you envision, that already means we could simplify (some of) the terrain graphics assets by a great deal. flat terrains and their transitions, for one.
20170629 12:03:04< vultraz_iOS> how so
20170629 12:03:21< DeFender> And I've said it before, but an image cache should be built up when the cfgs are parsed at game load, rather than when they're used. In the process of doing that, a spritesheet for every animation parsed and cached can be generated so that the cache being built up is made up of spritesheets instead of just raw images.
20170629 12:03:45< vultraz_iOS> yes, that's what I intend to do
20170629 12:03:51< vultraz_iOS> I'm just pondering the best way TO do it
20170629 12:04:02< vultraz_iOS> one sheet per prefix is what I was thinking
20170629 12:05:52< zookeeper> well you could do some transitions by blending and masking or whatnot, as well as different colour variants of some terrains by Magic VFX, etc
20170629 12:06:11< zookeeper> immediately cutting down on the amount of images needed for certain things
20170629 12:06:19< DeFender> vultraz_iOS, essentially, I suggest that at load time, there be a series of WML-context-aware code that runs recursively on the global CFG and is aware of what keys are images and what keys are animations, and builds up an image cache for each image, as well as a spritesheet for each animation (which it can pull from the cache and then composite together into a spritesheet). That way, each singular image (IPF-included) has its 
20170629 12:06:19< vultraz_iOS> need shaders for that
20170629 12:06:20< DeFender> own item in the cache, and each animation as a whole has its own spritesheet.
20170629 12:06:49< DeFender> Then at run-time, you just use those things from the cache.
20170629 12:06:53< vultraz_iOS> DeFender: uhhh........................................................
20170629 12:07:04< vultraz_iOS> I was just thinking putting the raw images together :|
20170629 12:07:21< DeFender> into a single spritesheet?
20170629 12:07:42< vultraz_iOS> raw images with one prefix into one sheet
20170629 12:07:57< DeFender> IINM, there's a maximum size above which the performance of a spritesheet drops of drastically.
20170629 12:08:14< DeFender> what do you mean by "prefix"?
20170629 12:08:22< zookeeper> even context-aware parsing code at loading time couldn't catch all images (because they can be constructed at runtime from variables etc), so that could only serve as an optional optimization step that could for sure catch 99% of everything
20170629 12:08:32< vultraz_iOS> for example, all images starting with "desert-road"
20170629 12:08:39< DeFender> zookeeper, yes, of course.
20170629 12:09:01< DeFender> vultraz_iOS, that's fair, though you'd still need to handle IPFs and such.
20170629 12:09:14 * vultraz_iOS curses soundly
20170629 12:09:41< DeFender> vultraz_iOS, also, if you're building spritesheets per-animation instead of per-prefix, then you're building exactly what you need rather than basing what you build on a somewhat tangential criterion.
20170629 12:10:07< vultraz_iOS> what....?
20170629 12:10:15 * zookeeper would still suggest just dumping IPF images into separate sheets... could still try to group them somehow if desired, maybe
20170629 12:10:34< vultraz_iOS> for the life of me I cannot understand what you're saying here
20170629 12:10:50< vultraz_iOS> it's not like we have randomly unused images somewhere
20170629 12:10:54< DeFender> Also, if you cache single images during this load process, and then build the spritesheet from those also at load, then you're not losing anything at runtime, since you'll still be using spritesheets then for anything that isn't a signle image.
20170629 12:11:20< DeFender> vultraz_iOS, argh. it's very hard to communicate this via text-only.
20170629 12:13:29< DeFender> what you're suggesting is to build spritesheets based on stuff that's stored together. That's a reasonable approach, since the things that are stored together are likely to be used together. However, what I'm suggesting is to actually parse the WML and build up the spritesheets based on what is ACTUALLY used together, rather than based on what will PROBABLY be. Get it?
20170629 12:15:31< DeFender> Like zookeeper said, it won't catch everything, but it'll be a heck of a lot better than making assupmtions, and it'll include relevant IPFs in the relevant spritesheet.
20170629 12:15:48< vultraz_iOS> Very difficult
20170629 12:15:51< vultraz_iOS> Hard to maintain
20170629 12:15:55< vultraz_iOS> Hard to implement
20170629 12:17:47< DeFender> I don't think any of that is true.
20170629 12:17:55< zookeeper> it's not necessarily hard to implement. it's basically just "wait until the WML tree is ready, then look at unit type WML and lump images contained within into per-unit sheets, then look at UI/theme/whatever WML and lump images contained within into a UI sheet, etc.
20170629 12:18:15< DeFender> zookeeper, exactly.
20170629 12:19:19< zookeeper> as said it'd just be an optional optimization step to get a few select things into more logical and possibly slightly more efficient sheets than if you just did it per-directory.
20170629 12:19:34< DeFender> and the beauty is that if something is updated and this pre-cacher isn't aware of it, it'll still get picked up at runtime.
20170629 12:19:47< zookeeper> of course i don't know if it _would_ be easy to implement :p
20170629 12:20:10< zookeeper> but since it's also optional it's not terribly relevant right now, since you'd still need to design all the rest first
20170629 12:20:19< vultraz_iOS> and what about terrain wml :|
20170629 12:20:34< DeFender> what about it? same exact process. not hard.
20170629 12:22:09< zookeeper> well, terrain images would essentially be grouped by directory. there's no (automatic) way to reliably tell which terrain a particular terrain graphics rule belongs to.
20170629 12:22:46< DeFender> ah, good point.
20170629 12:22:57< vultraz_iOS> DeFender: i don't see the benefit of using your method over my method
20170629 12:22:57< DeFender> it could also be grouped by rule.
20170629 12:23:18< zookeeper> then you'd have thousands of small sheets
20170629 12:23:49< DeFender> vultraz_iOS, the benefit is that your method won't actually add much optimization because most of the time any animation will involve images from multiple sheets and therefore you'll have to switch images anyway.
20170629 12:24:07< vultraz_iOS> what????
20170629 12:24:17< vultraz_iOS> I'm proposing 1 sheet per unit
20170629 12:24:19< vultraz_iOS> including animations
20170629 12:24:39< DeFender> vultraz_iOS, in fact, your method will end up slower in certain cases, because if an animation needs images from multiple sheets, and doesn't use every image in a given sheet, it'll be loading a larger image than it would with what we already have, just to throw away most of the image.
20170629 12:24:48< vultraz_iOS> images/units/humans-magi/arch-mage*.png includes the baseframe and all animations
20170629 12:25:04< DeFender> no, you're proposing one sheet per raw image group.
20170629 12:25:18< DeFender> I'M proposing one sheet per unit.
20170629 12:25:31< zookeeper> actually, is the "context switches are costly" thing really something that sheets would help with WRT unit animations? you still only need to render one texture per unit per frame.
20170629 12:25:35< vultraz_iOS> no I'm proposing one sheet per image group related to a unit!
20170629 12:25:37< zookeeper> JyrkiVesterinen, ^
20170629 12:25:56< vultraz_iOS> zookeeper: is it 
20170629 12:25:57< DeFender> animations involving IPFs, masks, other images, etc. will have to come from somewhere. Those son't be in your proposed sheets.
20170629 12:26:12< JyrkiVesterinen> zookeeper is right. You need to switch between multiple spritesheets per frame anyway.
20170629 12:26:36< DeFender> won't*
20170629 12:26:54< vultraz_iOS> well, yes, but..
20170629 12:27:08< vultraz_iOS> GAH i'm so confused
20170629 12:27:19< zookeeper> so whether the frames of one unit are on a single texture, or each in a separate texture, it doesn't matter because you still only draw one texture per unit per frame (usually, that is)
20170629 12:27:22< vultraz_iOS> that is true, and if you're drawing all the contexts of a hex per hex
20170629 12:27:28< DeFender> vultraz_iOS, essentially, 1. spritesheets aren't going to help as much as you think and 2. probably have nothing to do with the CPU issues you're experiencing.
20170629 12:27:30< vultraz_iOS> that means you go from terrain to unit to whatever
20170629 12:27:45< vultraz_iOS> unless i render all terrain first...
20170629 12:28:16< zookeeper> yeah, you probably can't sort it so that "draw all grass in one pass, then draw all spearmen in one pass, then draw all storm tridents in one pass"
20170629 12:28:34< DeFender> avoid scope creep. leave spritesheets for AFTER a_r is working properly.
20170629 12:28:47 * vultraz_iOS curses 
20170629 12:29:42< vultraz_iOS> ya know right now I can't even figure out a clear path forward because every single damn path seems to involved another thing to do and likewise that too
20170629 12:29:55< vultraz_iOS> I wanted to focus on the drawing queue 
20170629 12:29:55< DeFender> vultraz_iOS, scope creep.
20170629 12:30:07< DeFender> vultraz_iOS, so focus on the drawing queue.
20170629 12:30:11< vultraz_iOS> to do that I need to figure out how to sort shit into layers
20170629 12:30:28< vultraz_iOS> then I'm told that the sorting should be optimized 
20170629 12:31:02< DeFender> most of the time, sorting can be optimized after you have the basics working.
20170629 12:31:59< vultraz_iOS> i can't find a goddamn thread to grab to start work
20170629 12:32:01< vultraz_iOS> :|
20170629 12:33:05< zookeeper> vultraz_iOS, now, slowly, without panicking, look down. at your feet you see the bones of endless numbers of brave explorers who have ventured where you now stand. :>
20170629 12:36:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170629 12:37:29< vultraz_iOS> i could use the old drawing buffer code for the queue but then i want to add the ui code to the queue which means the fundamental nature of the queue needs to change and i just *don't know how to write it* 
20170629 12:38:12< vultraz_iOS> and if it needs to be written differently but then there's additional consideration about how things should really be implemented should i be writing something that's for an implementation that will be thrown out later 
20170629 12:38:41< vultraz_iOS> nothing makes sense anymore
20170629 12:48:08< zookeeper> remember hearing many times people say that making wesnoth use accelerated rendering is really hard? :P
20170629 12:48:34< DeFender> vultraz_iOS, if the ui stuff is always supposed to be above the map stuff, couldn't you just use the old code for the map stuff, have new code for the ui stuff, and then concatenate the two sets of layers?
20170629 12:48:39 * vultraz_iOS glares at zookeeper 
20170629 12:48:43< vultraz_iOS> very helpful
20170629 12:49:53< DeFender> or even start with the old code for the map stuff, and then add the ui stuff on top of it?
20170629 12:53:22< vultraz_iOS> alright, let me explain the dilemma again...
20170629 12:53:50< vultraz_iOS> as I explained to celmin earlier, the gamemap and UI hook into the main event context with two different handlers
20170629 12:54:10< DeFender> okay.
20170629 12:54:19< vultraz_iOS> the order in which events were passed to them dictated how the UI was drawn -over the map, or under it
20170629 12:54:47< vultraz_iOS> i have a local commit here that decouples drawing from events and simply calls the relevant functions directly at the end of the event dispatch
20170629 12:55:02< vultraz_iOS> that way i can handle other proper events correctly
20170629 12:55:30< vultraz_iOS> but as for drawing, i still need to call the drawing functions in reverse handler order
20170629 12:55:35< vultraz_iOS> so the UI one is called last
20170629 12:55:59< vultraz_iOS> but i don't really like this, since there's no real hard guarantee that will always be the case and it could break
20170629 12:56:14-!- Rhonda [~rhonda@anguilla.debian.or.at] has quit [Remote host closed the connection]
20170629 12:56:20< vultraz_iOS> if I'm adding a drawing queue, I was pondering whether the UI should utilize it
20170629 12:56:58< DeFender> does SDL not have something that says "draw this at layer 15, draw this at layer 253,987, draw this at layer 0" and then puts things where they belong?
20170629 12:57:21< vultraz_iOS> I came to the conclusion there's not much room in the current design for z-order specifications in the GUI2 wml but that it might be worth keeping a drawing layer for the UI at the top
20170629 12:57:43< JyrkiVesterinen> That sounds good to me.
20170629 12:58:17< vultraz_iOS> and then I got lost trying to figure out exactly how to implement the draw layering
20170629 12:59:14< vultraz_iOS> the most basic approach would be to push a data object with a texture ref, the x,y coords and/or map location, a possible clip rect, and layer to the queue, sort by the layer value
20170629 12:59:15< vultraz_iOS> then draw
20170629 12:59:21< vultraz_iOS> but that's horribly inefficient 
20170629 12:59:59-!- Rhonda [~rhonda@anguilla.debian.or.at] has joined #wesnoth-dev
20170629 13:15:39< DeFender> vultraz_iOS, optimize later. a_r, even with something "horribly inefficient" will likely be a massive step up from what we have now.
20170629 13:20:38< zookeeper> exactly. as long as it performs better than now and doesn't break horribly for 50% of users, it's a success.
20170629 13:29:03-!- Sp4rrowh4wk [~me@gnusrv3.epfl.ch] has joined #wesnoth-dev
20170629 13:33:30< Sp4rrowh4wk> Hi all, I was wondering if anyone had ever thought about / started writing an LDAP-backed user handler for wesnothd; and secondly since most LDAP implementations follow an RFC'd C API, I know C but only little C++ and there doesn't seem to be a standard LDAP library in C++ (some small projects on GH, but nothing we wouldn't end up maintaining at the same time): is it a terrible problem if I write said
20170629 13:33:33< Sp4rrowh4wk> handler in (clean) C? I've read the contributing guide and all, but well... if the answer is no, I don't have the time to learn a new language right now ^^
20170629 13:35:32< Sp4rrowh4wk> (RFC in question is https://tools.ietf.org/html/rfc1823)
20170629 13:41:48< Soliton> the user handler is a class. you can't write that in C. you can call some C LDAP lib in it though.
20170629 13:48:00< Sp4rrowh4wk> Soliton: yes, I misexplained myself: I would write a handler class corresponding to the sample_user_handler public API, but inside using C to communicate with the LDAP server
20170629 13:54:51< Soliton> i'd say that's acceptable. we're using C libraries in wesnoth right now.
20170629 13:56:21< Sp4rrowh4wk> Soliton: ok. I'll try to write a POC version and then submit it to you guys then, see what you think
20170629 13:57:47< Soliton> cool.
20170629 14:34:03-!- JyrkiVesterinen [~JyrkiVest@85-76-74-69-nat.elisa-mobile.fi] has quit [Quit: .]
20170629 15:13:14-!- jatenk [~jatenk@185-23-224-16.lsn8.wtnet.de] has joined #wesnoth-dev
20170629 15:13:47< jatenk> hey guys!
20170629 15:14:27< jatenk> currently going through my macOS applications to find out which are 32 bit, which Apple will stop supporting in two years - are there plans to get Wesnoth to run as 64 bit?
20170629 15:19:25< Soliton> pretty sure the mac builds are 32 and 64 bit.
20170629 15:24:13< jatenk> system report shows it as not 64 bit
20170629 15:24:36< jatenk> and not under the 64 bit category
20170629 15:24:45< jatenk> or is that new? I haven’t updated in a few months
20170629 15:24:47< jatenk> maybe a year
20170629 15:26:34-!- Kwandulin [~Kwandulin@p200300760F2142F641E27F242FBE320D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170629 15:27:37< Soliton> i don't know much about macs but it says 32 and 64 bit here at least: https://github.com/wesnoth/wesnoth/tree/master/projectfiles/Xcode
20170629 15:31:14< jatenk> yeah, that’s if I build it myself
20170629 15:31:28< jatenk> but I’m not a dev, as most players, so that’s not happening ^^
20170629 15:31:42< jatenk> the standard bundle seems to get built with 32 bit
20170629 15:31:48< jatenk> or rather, installer
20170629 15:32:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170629 15:32:15-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170629 15:32:21< Sp4rrowh4wk> oh the dmg on wesnoth.org you probably mean
20170629 15:32:54< jatenk> yeah
20170629 15:33:07< Soliton> why is it different if you build it yourself or the mac packager?
20170629 15:33:39< Sp4rrowh4wk> There's a binary package (dmg) on the wesnoth website you can download and install without building anything
20170629 15:34:12< Soliton> and it came to be by magic!
20170629 15:34:20< Sp4rrowh4wk> exactly :)
20170629 15:34:32< Soliton> alright, i understand the reasoning now.
20170629 15:37:46-!- stikonas_ is now known as stikonas
20170629 15:38:09< jatenk> Sp4rrowh4wk: so, is 64 bit for the dmg planned?
20170629 15:38:24< Sp4rrowh4wk> jatenk: don't ask me, I'm a newbie here ^^
20170629 15:38:27< jatenk> oh.
20170629 15:38:33< Sp4rrowh4wk> I don't know who takes care of the build servers
20170629 15:39:27< Sp4rrowh4wk> just interfered because I thought I had understood your problem and try to bridge
20170629 15:39:30< jatenk> kk
20170629 15:46:44< Soliton> did you see that it literally says on that page that the release configuration (which builds 32 and 64 bit) is used for official releases?
20170629 15:48:11< jatenk> not sure what you mean, but I know that the app I have right now is 32 bit as I checked that on my computer?
20170629 15:53:11< Sp4rrowh4wk> jatenk: can you check metadata on the .dmg? 
20170629 15:53:36-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 268 seconds]
20170629 15:54:29< Sp4rrowh4wk> Soliton: looking at the binary download page on sourceforge (https://sourceforge.net/projects/wesnoth/files/wesnoth-1.12/wesnoth-1.12.6/) shows that the only windows binary is 32 bits -- it would be reasonable to assume that the mac one is as well ? Though I agree that it is counter intuitive
20170629 15:54:30< jatenk> Sp4rrowh4wk: how?
20170629 15:54:53< Sp4rrowh4wk> jatenk: dunno, right click -> properties? I don't have a mac, I dunno ^^
20170629 15:55:15< jatenk> Sp4rrowh4wk: doesn’t show wether it’s 32 or 64 bit, but I’ll see wether I can find something
20170629 15:57:21< Soliton> it'd be much more useful to check 1.13. it's possible 1.12 was 32 bit only.
20170629 15:57:59< Soliton> would still surprise me if it were.
20170629 16:02:31< Soliton> well, looks like 1.12 is indeed only 32 bit but still supports ppc.
20170629 16:02:56< jatenk> cool, which is about 10 people in the world ^^
20170629 16:03:11< Soliton> so you'll have to check 1.13 as mentioned to see that it's 32 nd 64 bit now.
20170629 16:04:06< jatenk> I can’t check the dmg, no idea how one would do that or if that even makes sense since it’s not an app but a package, like zip or rar
20170629 16:04:10< jatenk> yeah, on it
20170629 16:08:50< jatenk> side note: damn, this game grew. it’s one of the first games I ever played, at least 10 years ago, and I played it quite a lot back then
20170629 16:10:16< jatenk> looking good, the binaries are 64 bit
20170629 16:10:46< jatenk> yep, the whole app is
20170629 16:10:53< jatenk> all set for the next 10 years! :D
20170629 16:12:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 16:13:21-!- Kwandulin [~Kwandulin@p200300760F2142F641E27F242FBE320D.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170629 16:13:27< jatenk> alright, thanks for your help guys. take care!
20170629 16:14:25-!- jatenk [~jatenk@185-23-224-16.lsn8.wtnet.de] has left #wesnoth-dev []
20170629 16:30:43-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20170629 16:40:32-!- esr [~esr@wesnoth/developer/esr] has quit [Quit: WeeChat 1.4]
20170629 16:43:56-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20170629 16:44:28-!- esr [~esr@wesnoth/developer/esr] has quit [Client Quit]
20170629 16:44:37-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20170629 16:54:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170629 16:56:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 16:57:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: No route to host]
20170629 16:58:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 17:12:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20170629 17:13:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170629 17:13:51-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170629 17:35:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170629 17:35:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 17:36:30-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 17:36:40-!- horrowind [~Thunderbi@p2003008E6C0B26C5964452FFFE0220ED.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170629 17:40:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20170629 18:06:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170629 18:06:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170629 18:16:42-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 258 seconds]
20170629 18:26:16-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20170629 18:42:24-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170629 18:59:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170629 19:00:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170629 19:04:13-!- sevu [~Shiki@p54855C10.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170629 19:23:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170629 19:24:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170629 19:49:44-!- sevu [~Shiki@p54855C10.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20170629 20:16:33-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170629 20:16:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170629 20:25:50-!- mjs-de [~mjs-de@x4e31e9ee.dyn.telefonica.de] has joined #wesnoth-dev
20170629 20:27:19< zookeeper> so, with mattsc kind of away, who's the next person with the most knowledge about the AI? celmin?
20170629 20:41:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170629 20:41:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170629 20:53:02< DeFender> zookeeper, he gave me a crash course once... :P
20170629 21:06:09-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170629 21:29:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170629 21:29:13-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170629 21:38:11-!- mjs-de [~mjs-de@x4e31e9ee.dyn.telefonica.de] has quit [Remote host closed the connection]
20170629 21:51:27-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170629 21:57:30-!- heirecka [~heirecka@exherbo/developer/heirecka] has quit [Ping timeout: 258 seconds]
20170629 21:59:43-!- heirecka [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev
20170629 22:28:48-!- atarocch [~atarocch@93.56.160.37] has quit [Remote host closed the connection]
20170629 22:52:16-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 255 seconds]
20170629 23:26:49-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170629 23:32:00-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170629 23:32:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170629 23:42:41-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20170629 23:45:08-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170629 23:46:50-!- horrowind [~Thunderbi@p2003008E6C0B26C5964452FFFE0220ED.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20170629 23:50:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170629 23:55:22-!- horrowind [~Thunderbi@p2003008E6C0B26C5964452FFFE0220ED.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170629 23:57:30< shadowm> https://wiki.wesnoth.org/WesnothTranslationsHowTo   
20170629 23:58:13< shadowm> Could somebody within the next week add instructions for content creators here?
20170629 23:59:15< shadowm> Also, unless anybody objects, I'm going to drop the gettext.wesnoth.org WesCamp functionality.
20170629 23:59:22< shadowm> This weekend.
20170629 23:59:27-!- horrowind [~Thunderbi@p2003008E6C0B26C5964452FFFE0220ED.dip0.t-ipconnect.de] has quit [Client Quit]
--- Log closed Fri Jun 30 00:00:19 2017