--- Log opened Tue Jun 16 00:00:20 2015
20150616 00:01:23-!- kex [~kex@89.205.79.252] has quit [Read error: Connection reset by peer]
20150616 00:01:36-!- kex [~kex@89.205.79.252] has joined #wesnoth-dev
20150616 00:01:44-!- [Relic] [~Relic]@2602:306:33a3:6d30:d926:a794:81f2:8a0] has joined #wesnoth-dev
20150616 00:04:33< shadowm> More importantly I want to know if it's worth keeping this in master or should have someone else start from scratch.
20150616 00:05:17< shadowm> I don't want to have to convince people to take a look at a half-done project only for them to find out that it's compile-time-broken.
20150616 00:07:51< shadowm> I'd also rather not maintain two separate backends since one of them will inevitably suffer from code rot, and right now the SDL 1.2.x backend is much better maintained.
20150616 00:08:37< shadowm> We don't have the human power anymore, so it's time to opt for a more pragmatic approach to maintainability even if it means dropping support for things.
20150616 00:09:47< shadowm> The worse this mess gets, the greater the entry barrier for new developers, which is exactly what we don't if we are to release Wesnoth 1.14 before 2039.
20150616 00:10:14< shadowm> *want if
20150616 00:10:19-!- [Relic] [~Relic]@2602:306:33a3:6d30:d926:a794:81f2:8a0] has quit [Quit: I press the magic X and all the weirdos go away!]
20150616 00:10:32< lipkab> I'll try to give a comprehensive overview of how SDL2, SDL_gpu and Wesnoth relate to each other.
20150616 00:10:34< lipkab> So.
20150616 00:10:48< lipkab> SDL 1.2 has surfaces.
20150616 00:11:24< StandYourGround> like Microsoft? jk
20150616 00:11:33< lipkab> SDL 2 has surfaces too, but it also has textures which are hardware-accelerated thus they are supposed to be fast.
20150616 00:12:31< lipkab> The original plan was, move Wesnoth to SDL2 and then replace surfaces with textures and presto, we have hardware-accelerated graphics.
20150616 00:13:10< lipkab> Then it turned out that SDL 2 textures suck.
20150616 00:13:25< shadowm> Then how do other games manage to use SDL 2?
20150616 00:13:44< shadowm> For example, the Anura engine, which is used by Frogatto.
20150616 00:14:18< lipkab> AFAIK Anura uses an embedded OpenGL context rather than SDL's texture API.
20150616 00:15:33< lipkab> So we (I and mordante) decided to ditch SDL2 and moved to SDL_gpu, which also has a similar API, which sucks less.
20150616 00:16:37< shadowm> "ditch SDL 2" -- but SDL_gpu uses SDL 2, doesn't it?
20150616 00:16:37< lipkab> A big part of the game has been ported to SDL_gpu (GUI2 not, so that's why you can't see the titlescreen), but then...
20150616 00:16:39< StandYourGround> are there any pre-built GPL compatible graphics engines that could be used, or is it necessary to build Wesnoth's graphics engine from scratch>
20150616 00:17:02< lipkab> ...it turned out to be slower than before.
20150616 00:17:24< shadowm> I'm getting a feeling of déjà vu from that statement alone.
20150616 00:18:03< shadowm> There were two previous attempts to make Wesnoth use OpenGL (with SDL 1.2, though, because SDL 2 didn't exist at the time) and both hit performance issues.
20150616 00:18:07< lipkab> Which is not SDL_gpu's fault (in contrary to what iceiceice thinks), but a consequence of how Wesnoth's graphics engine is built.
20150616 00:18:24< shadowm> If anything that suggests that Wesnoth's rendering engine needs to be rebuilt from scratch, yes.
20150616 00:19:03< shadowm> And I'd not be opposed to that at all given how absurdly broken its design is right now.
20150616 00:19:17< lipkab> When you use hardware rendering the number of textures is a critical factor.
20150616 00:19:58< lipkab> Wesnoth loads every single sprite into a different buffer which leaves the VGA with hundreds of textures to handle.
20150616 00:20:02-!- [Relic] [~Relic]@2602:306:33a3:6d30:8112:7a09:bdf0:c87a] has joined #wesnoth-dev
20150616 00:20:24< lipkab> That is what's killing performance.
20150616 00:20:36< lipkab> So the situation right now:
20150616 00:20:38-!- irker750 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20150616 00:20:38< irker750> wesnoth: gfgtdf wesnoth:master 219bb24b30d7 / data/multiplayer/eras.cfg: disable turn over advantage for campaigns by default http://git.io/vLqNh
20150616 00:20:40< irker750> wesnoth: gfgtdf wesnoth:master 634d29020fe8 / data/multiplayer/ (eras.cfg eras.lua): dont make 4mp leader quick in campaigns by default http://git.io/vLqNj
20150616 00:21:03< lipkab> gfgtdf: Thank you for interrupting me!
20150616 00:21:07< lipkab> So.
20150616 00:21:28< shadowm> I can edit out the noise from my log.
20150616 00:21:54< lipkab> In order to make any hardware acceleration magic work, we need to fix the engine first.
20150616 00:22:44< lipkab> At a very minimum, that requires organizing sprites into larger buffers (i.e. another attempt at the failed spritesheet project).
20150616 00:23:34< shadowm> Is it not possible to read them from disk (into a temporary software surface if necessary) and just throw them into an internal monolithic texture?
20150616 00:23:56< shadowm> That'd save us having to decide exactly how to implement spritesheets as an API.
20150616 00:24:37< lipkab> Sure, sure, but that still needs quite some reorganizing in image.cpp et al.
20150616 00:25:39< shadowm> It's still less work than defining a spritesheets API task and converting all existing content to it.
20150616 00:25:42< lipkab> So when the engine is fixed can we really talk about whether to choose SDL2 + OpenGL (plain SDL2 is a no-go), or SDL_gpu.
20150616 00:25:44< shadowm> s/task//
20150616 00:26:20< shadowm> But this approach wouldn't work with software surfaces in the interim, right?
20150616 00:27:56< lipkab> It won't fit well, but I think it can be done.
20150616 00:28:59< lipkab> The surface class needs to be juiced up with a source rectangle used for blitting.
20150616 00:30:42< lipkab> shadowm: I'm obviously biased so I don't want to make the decision on whether existing SDL_gpu code should be kept around.
20150616 00:30:42< shadowm> Without going into the implementation details and assuming the best, that'd be the image cache component of the engine sorted. However, what about the display engine itself (in charge of the hex map and, for some stupid historical reason, theme UI elements)? And what about GUI2, which we should assume is unmaintained like the rest right now?
20150616 00:31:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20150616 00:31:49< shadowm> GUI1 is straightforward enough in its usage of surfaces, but AFAIK GUI2 has another layer of abstraction on top of them in the form of GUI2 canvases.
20150616 00:32:14< shadowm> (Note: GUI1 is straightforward. The legacy font API, which it uses, is not.)
20150616 00:32:51< lipkab> The problem with the map display is that it uses optimizations that rely on read-write access to graphic buffers.
20150616 00:33:22< shadowm> (Or to look at it another way, the image cache (which is the API for loading images from files) is only *one* big surface user.)
20150616 00:33:34-!- kex [~kex@89.205.79.252] has quit [Remote host closed the connection]
20150616 00:33:40< lipkab> Hardware graphics typically only provide write access.
20150616 00:34:46< shadowm> You can normally take screenshots of applications that use OGL or D3D.
20150616 00:34:54< lipkab> Presumably, better hardware would make up for the performance losses when using accelerated graphics.
20150616 00:35:38< lipkab> But users stuck with software rendering for some reason would likely experience a serious performance drop.
20150616 00:36:41< shadowm> Forget about software rendering, we can drop official support for it entirely since it obviously complicates matters more than the cross-vendor GPU support clusterfuck alone does.
20150616 00:36:42< lipkab> shadowm: You can't read texture data in OGL, I know that one for sure.
20150616 00:37:04< shadowm> Okay, then how can I take screenshots of OGL applications?
20150616 00:37:12-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20150616 00:38:00< lipkab> I guess you are taking snapshots from the screen's framebuffer, not the videocard's.
20150616 00:39:05< shadowm> The application's render results somehow find their way back to VM, though.
20150616 00:40:18< shadowm> Oh, okay, I think you are saying the screen's framebuffer sits at the end of the pipeline and can be read from.
20150616 00:40:44< lipkab> Yeah.
20150616 00:40:52< shadowm> Mind if I share this conversation with Dave later?
20150616 00:41:06< lipkab> Of course not.
20150616 00:42:17< lipkab> shadowm: Do you have any more questions right now?
20150616 00:44:14< lipkab> Well, if you have, it will have to wait.
20150616 00:44:18< lipkab> Bye!
20150616 00:44:18-!- lipkab [~lipkab@host-91-147-210-193.biatv.hu] has quit [Quit: Távozom]
20150616 00:45:49< shadowm> lipkab: Well, yes, you answered the display engine question but not the GUI2 question.
20150616 01:02:40-!- travis-ci [~travis-ci@ec2-54-82-36-252.compute-1.amazonaws.com] has joined #wesnoth-dev
20150616 01:02:41< travis-ci> wesnoth/wesnoth#6637 (master - 634d290 : gfgtdf): The build was fixed.
20150616 01:02:41< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/66956140
20150616 01:02:41-!- travis-ci [~travis-ci@ec2-54-82-36-252.compute-1.amazonaws.com] has left #wesnoth-dev []
20150616 01:19:46< StandYourGround> Well, I finally have homebrew working right. So if I get mupen64plus to install again, I'll think wesnoth worth the try
20150616 01:20:44-!- [Relic] [~Relic]@2602:306:33a3:6d30:8112:7a09:bdf0:c87a] has quit [Quit: I press the magic X and all the weirdos go away!]
20150616 01:54:36-!- StandYourGround [~Adium@2602:306:83db:de50:5014:ed7f:ec04:fb16] has quit [Quit: Leaving.]
20150616 03:00:19-!- StandYourGround [~Adium@2602:306:83db:de50:5014:ed7f:ec04:fb16] has joined #wesnoth-dev
20150616 03:01:30-!- StandYourGround [~Adium@2602:306:83db:de50:5014:ed7f:ec04:fb16] has quit [Client Quit]
20150616 03:10:12-!- Kwandulin [~Miranda@p5B009F37.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150616 03:21:16-!- irker750 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20150616 03:25:35-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 250 seconds]
20150616 03:27:37-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20150616 03:29:22-!- SpoOkyMagician [~chatzilla@cpe-74-136-81-20.kya.res.rr.com] has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.6/20150605094246]]
20150616 03:29:23-!- [Relic] [~Relic]@2602:306:33a3:6d30:5052:4bb3:3c75:b2c2] has joined #wesnoth-dev
20150616 03:35:56-!- Appleman1234 [~Appleman1@KD106154008167.au-net.ne.jp] has joined #wesnoth-dev
20150616 03:38:46-!- [Relic] [~Relic]@2602:306:33a3:6d30:5052:4bb3:3c75:b2c2] has quit [Ping timeout: 265 seconds]
20150616 04:11:10-!- Kwandulin [~Miranda@p5B009F37.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150616 04:18:21-!- Appleman1234_ [~Appleman1@KD106154004209.au-net.ne.jp] has joined #wesnoth-dev
20150616 04:20:57-!- Appleman1234 [~Appleman1@KD106154008167.au-net.ne.jp] has quit [Ping timeout: 240 seconds]
20150616 04:33:28-!- Appleman1234_ is now known as Appleman1234
20150616 05:08:48-!- [Relic] [~Relic]@2602:306:33a3:6d30:945b:954e:49e5:a35d] has joined #wesnoth-dev
20150616 05:16:36-!- [Relic] [~Relic]@2602:306:33a3:6d30:945b:954e:49e5:a35d] has quit [Ping timeout: 256 seconds]
20150616 05:44:23< shadowm> !wss
20150616 05:44:23< shikadibot> shadowm: DNS: Online Web: Online Forums: Online Wiki: Online Add-ons: Online MP #1: Online MP #2: Online MP #3: Online
20150616 05:44:26< shikadibot> shadowm: Last updated: 5 minutes ago
20150616 05:49:12-!- [Relic] [~Relic]@2602:306:33a3:6d30:d47c:87fb:914e:fec7] has joined #wesnoth-dev
20150616 05:59:35-!- ]Relic[ [~Relic]@2602:306:33a3:6d30:7045:3ffe:e4c7:c481] has joined #wesnoth-dev
20150616 06:02:48-!- [Relic] [~Relic]@2602:306:33a3:6d30:d47c:87fb:914e:fec7] has quit [Ping timeout: 265 seconds]
20150616 06:19:57-!- [Relic] [~Relic]@2602:306:33a3:6d30:2808:e5a6:b19c:adde] has joined #wesnoth-dev
20150616 06:21:39-!- ]Relic[ [~Relic]@2602:306:33a3:6d30:7045:3ffe:e4c7:c481] has quit [Ping timeout: 265 seconds]
20150616 06:41:42-!- ]Relic[ [~Relic]@2602:306:33a3:6d30:68b7:f7f9:482:20a5] has joined #wesnoth-dev
20150616 06:44:22-!- [Relic] [~Relic]@2602:306:33a3:6d30:2808:e5a6:b19c:adde] has quit [Ping timeout: 265 seconds]
20150616 06:46:15-!- ]Relic[ is now known as [Relic]
20150616 06:48:01-!- stth [~stth@ip-176-198-117-134.hsi05.unitymediagroup.de] has quit [Quit: Leaving...]
20150616 06:50:46-!- [Relic] [~Relic]@2602:306:33a3:6d30:68b7:f7f9:482:20a5] has quit [Quit: I press the magic X and all the weirdos go away!]
20150616 06:55:42-!- stth [~stth@ip-176-198-117-134.hsi05.unitymediagroup.de] has joined #wesnoth-dev
20150616 07:24:17-!- Appleman1234_ [~Appleman1@KD106178175107.au-net.ne.jp] has joined #wesnoth-dev
20150616 07:27:04-!- Appleman1234 [~Appleman1@KD106154004209.au-net.ne.jp] has quit [Ping timeout: 272 seconds]
20150616 07:30:02-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20150616 07:47:28-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20150616 07:58:23-!- lipkab [~lipkab@host-91-147-210-193.biatv.hu] has joined #wesnoth-dev
20150616 07:59:31< lipkab> shadowm: I don't have a really good understanding on GUI2's internals.
20150616 08:00:11< lipkab> From what I know, it has the same problem as the map display, relying on read access to surface/texture contents.
20150616 08:04:26< shadowm> Well, there's a problem with that argument, lipkab.
20150616 08:04:49< lipkab> Yes?
20150616 08:04:53< shadowm> https://www.opengl.org/sdk/docs/man2/xhtml/glReadPixels.xml
20150616 08:05:22< shadowm> 01:10:43 shadowm: e.g. https://github.com/anura-engine/anura/blob/trunk/src/kre/DisplayDeviceOGL.cpp#L674
20150616 08:05:35< lipkab> Boom! That's a surprise.
20150616 08:05:46< shadowm> I know, right?
20150616 08:06:34< shadowm> There is a pattern I'm seeing here.
20150616 08:06:55< shadowm> GUI2. GUI2 MP lobby. SDL 2 transition.
20150616 08:09:23< shadowm> umcd add-ons server.
20150616 08:09:56< shadowm> Scenario editor. Qt GUI branch. Hotkey settings redesign.
20150616 08:10:08< shadowm> Whiteboard.
20150616 08:10:27< shadowm> New storyscreen API.
20150616 08:10:32< lipkab> Hey!
20150616 08:10:41< shadowm> SP/MP unification project take 1.
20150616 08:10:47< lipkab> What's wrong with the new storyscreen API?
20150616 08:10:47< shadowm> SP/MP unification project take 2.
20150616 08:10:56< shadowm> Gamestate code refactoring.
20150616 08:11:52< shadowm> Spritesheets.
20150616 08:12:14< shadowm> OpenGL branch 1. OpenGL branch 2.
20150616 08:12:53< shadowm> All overly ambitious endeavors.
20150616 08:14:03< lipkab> So let's drown ourselves into a cup of lemonade or what?
20150616 08:14:18< shadowm> Tell me how many active developers we have right now.
20150616 08:14:28< lipkab> Well, we have you...
20150616 08:14:39< lipkab> ...gfgtdf, iceiceice...
20150616 08:14:47< shadowm> iceiceice is not active anymore.
20150616 08:14:53< lipkab> Uhm.
20150616 08:15:04< lipkab> Me, sort of...
20150616 08:15:07< shadowm> I don't count because my skillset is very narrow and so is my patience to deal with a broken codebase.
20150616 08:15:49< lipkab> mattsc.
20150616 08:16:02< shadowm> Engine developers. mattsc only does Lua and WML.
20150616 08:16:31< lipkab> Then me and gfgtdf, I guess.
20150616 08:16:47-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 250 seconds]
20150616 08:16:59< lipkab> That's still two people!
20150616 08:17:10< shadowm> gfgtdf doesn't do graphics, otherwise I'm sure he'd have taken over the SDL_gpu effort in your absence.
20150616 08:17:29< shadowm> That narrows it down to one developer for that particular task.
20150616 08:17:53< lipkab> At least I won't have any interference :P
20150616 08:18:22-!- cib0 [~cib@p5DC75F4D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150616 08:18:31-!- shadowm_desktop [ignacio@181.43.66.214] has joined #wesnoth-dev
20150616 08:18:32< shadowm> So, unless you think you can somehow churn out code for a replacement engine like there's no tomorrow and have us running on SDL 2 before 2039...
20150616 08:18:43-!- shadowm_desktop [ignacio@181.43.66.214] has quit [Changing host]
20150616 08:18:43-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20150616 08:19:13< shadowm> We have a very slow and boring future ahead, I think.
20150616 08:20:23< shadowm> All the projects above share a common aspect. Their authors or mentors underestimated the amount of work it'd take to complete or perfect them.
20150616 08:21:13< lipkab> Except the storyscreen API which is absolutely finished and is pretty cool.
20150616 08:21:15< shadowm> They also underestimated the amount of time it'd take to get them done.
20150616 08:21:39< shadowm> I hate the storyscreen API and it doesn't actually fulfill the original purpose.
20150616 08:22:42< lipkab> The original purpose was to allow multiple background layers and it definitely allows multiple background layers.
20150616 08:23:01< shadowm> I... what.
20150616 08:23:10< shadowm> That's not its original purpose.
20150616 08:23:21< shadowm> At least it wasn't for the version *I* wrote.
20150616 08:23:48< shadowm> Has it been replaced since then? The original purpose was to get a GUI2 implementation running.
20150616 08:24:22< lipkab> Uhm... I was talking about the code I wrote when zookeeper made those cool new maps.
20150616 08:24:51< lipkab> Okay, let's forget about that.
20150616 08:26:43< lipkab> Back on topic: I can't make any promises about SDL2/SDL_gpu/OpenGL at this point.
20150616 08:28:37< lipkab> I'd like to have the spritesheet stuff up and running first.
20150616 08:29:35< lipkab> Then a prototype rendering engine outside of Wesnoth.
20150616 08:30:05< shadowm> As I said, I consider the WML aspect of it a distraction that AFAICT can be put off (and *should* be if possible).
20150616 08:30:43< lipkab> Only after that should we take on the monster that the Wesnoth graphics engine is.
20150616 08:31:03< shadowm> Have you ever considered Anura?
20150616 08:31:54< lipkab> At a "what if" level, yes, but I haven't done any research.
20150616 08:32:40< shadowm> Considering that their lead developer is none other than our founding developer, there may be things we can learn from Anura.
20150616 08:33:32< zookeeper> i wonder if from the outside it looks like we need/want any new dedicated coders to do major projects.
20150616 08:33:46< shadowm> We may even be able to use Anura itself if someone writes a hex tiling engine on top of it, I've been told.
20150616 08:34:41< lipkab> My greatest concern about Anura is that it uses its own scripting language.
20150616 08:34:57< shadowm> Lua support was added to it recently.
20150616 08:35:09< lipkab> That's not the problem.
20150616 08:35:18< lipkab> But how about WML?
20150616 08:35:45< shadowm> Existing content, I know. Of all the people here I should know how much of a pain it'd be to port WML content even with partial automation.
20150616 08:36:22< shadowm> So what we have above is a list of unfinished projects or finished projects with unmet expectations piling up and throwing Wesnoth's codebase into disarray. Up to version 1.11.10, we managed to cope with bandaid-style fixes mostly thanks to there being established developers with a firm grasp of their own code.
20150616 08:38:20< lipkab> Maybe we should fork ourselves :P
20150616 08:38:38< shadowm> Some of them are fairly inconsequential (storyscreen API), can be easily reverted or pushed aside in some way (GUI2 MP lobby), outright ignored (umcd), or bandaid-fixed (GUI2, SP/MP UP).
20150616 08:39:13< shadowm> But all of them are symptoms of a chronic disease.
20150616 08:40:48< shadowm> You can't just throw Wesnoth's code at someone (especially unpaid) and expect them to e.g. re-engineer the graphics engine or fix GUI2's bugs and add the missing functionality.
20150616 08:41:17< shadowm> Especially since in some cases the code in question is vastly underdocumented.
20150616 08:42:12< shadowm> Letting new people do as they wish is not a sure ticket to rainbow ponies paradise either since that's exactly how some of the aforementioned endeavors came to be in the first place.
20150616 08:42:48< shadowm> Ignoring the issues altogether got us here.
20150616 08:43:58< shadowm> And to answer zookeeper's question, new developers don't grow on trees.
20150616 08:44:27< shadowm> Look at the forums and see how much activity there is nowadays compared to 2007 or 2008.
20150616 08:45:08< shadowm> We have an issue of visibility, but we would also do ourselves a disservice by publicizing us in our current state.
20150616 08:47:18< zookeeper> yes, i was wondering why that is. why did we used to have much more people able to pull off even big'ish projects, what's changed in the past X years?
20150616 08:50:18< lipkab> shadowm: Given that, due to the well-noted lack of workforce, we can't fix this mess in the foreseeable future, you should just stop worrying about it.
20150616 08:50:46< lipkab> Let's concentrate on what we can do instead of what we can't.
20150616 08:52:00< lipkab> For starters I'm curious what benefits the SP/MP unification was supposed to bring us.
20150616 08:52:33< lipkab> Because frankly, the whole doesn't make any sense to me and it's apparently causing loads of bugs.
20150616 08:52:45< lipkab> *whole thing
20150616 08:53:05< shadowm> (Reminds me I still need to see if gfgtdf's patch fixes at least half of the 1.13.1 blockers.)
20150616 08:53:50< shadowm> I honestly don't know. I also sent the student an email on May 30 and still haven't heard from them.
20150616 08:54:44< shadowm> However, from a conversation I had with gfgtdf what I get is that it should simplify support for MP campaigns in some vague way.
20150616 08:58:12< lipkab> Okay, since gfgtdf knows the most about this project we should ask him if it's worth keeping.
20150616 08:58:43< lipkab> He did mention reverting everything as an option recently.
20150616 09:04:22-!- mjs-de [~mjs-de@129.217.43.93] has joined #wesnoth-dev
20150616 09:04:50-!- prkc [~prkc@catv-89-134-173-244.catv.broadband.hu] has joined #wesnoth-dev
20150616 09:13:56-!- lipkab [~lipkab@host-91-147-210-193.biatv.hu] has quit [Quit: Távozom]
20150616 09:34:46-!- cib0 [~cib@p5DC75F4D.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20150616 10:09:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150616 10:23:08-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 272 seconds]
20150616 10:47:30-!- Appleman1234_ is now known as Appleman1234
20150616 11:01:27-!- hay207 [~haythamme@41.34.57.57] has joined #wesnoth-dev
20150616 11:19:25-!- cib0 [~cib@132.231.178.94] has joined #wesnoth-dev
20150616 11:22:18-!- gfgtdf [~chatzilla@f054138228.adsl.alicedsl.de] has joined #wesnoth-dev
20150616 11:30:20< gfgtdf> lipkap: online?
20150616 11:54:10-!- cib0 [~cib@132.231.178.94] has quit [Ping timeout: 265 seconds]
20150616 12:01:39-!- Appleman1234_ [~Appleman1@KD106178169227.au-net.ne.jp] has joined #wesnoth-dev
20150616 12:04:36-!- Appleman1234 [~Appleman1@KD106178175107.au-net.ne.jp] has quit [Ping timeout: 256 seconds]
20150616 12:08:18-!- gfgtdf [~chatzilla@f054138228.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.5/20150525141253]]
20150616 12:37:59-!- Kwandulin [~Miranda@p5B009F37.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150616 12:47:20-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150616 14:11:08-!- kex [~kex@31.11.67.182] has quit []
20150616 14:12:33-!- kex [~kex@89.205.79.252] has joined #wesnoth-dev
20150616 15:06:09-!- gfgtdf [~chatzilla@f054138228.adsl.alicedsl.de] has joined #wesnoth-dev
20150616 15:06:59-!- horrowin1 [~Icedove@2a02:810a:8b00:5298:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20150616 15:07:30-!- Appleman1234__ [~Appleman1@KD106154014212.au-net.ne.jp] has joined #wesnoth-dev
20150616 15:10:06-!- Appleman1234_ [~Appleman1@KD106178169227.au-net.ne.jp] has quit [Ping timeout: 264 seconds]
20150616 15:13:33-!- cib0 [~cib@132.231.178.71] has joined #wesnoth-dev
20150616 15:19:44-!- Kexoth [~kex@31.11.67.182] has joined #wesnoth-dev
20150616 15:20:39-!- kex [~kex@89.205.79.252] has quit [Ping timeout: 245 seconds]
20150616 15:30:59-!- cib0 [~cib@132.231.178.71] has quit [Ping timeout: 250 seconds]
20150616 15:49:33-!- Kexoth [~kex@31.11.67.182] has quit [Remote host closed the connection]
20150616 15:50:19< gfgtdf> lipkap: I agree that most mp features like changing fog/shroud/turns/random_start_time or changing fations leaders and genders don't make sense in Campaigns
20150616 15:50:53< gfgtdf> libkap: and i am also not really happy with the current show_connect etc features in sp.
20150616 15:51:34< gfgtdf> libkap: But i also think that some of the mp features ([modification]s and [option]s) are useful in sp too
20150616 15:52:37< gfgtdf> lipkab: Also what i said before about that these things don't make sense in campaigns is also true for multiplayer campaigns.
20150616 15:54:33< gfgtdf> libkap: so i think it makes more sense to have these things in 'normal mp maps' but not in 'campaigns' by default where it doesn't matter whether sp or mp campaigns.
20150616 15:56:12< gfgtdf> libkap: and in mp campaigns we need the mp connect stuff, even if we don't want the user to be able to change factions/leaders usually.
20150616 16:00:39< gfgtdf> libkap: so i think it is desirable that campaigns work in mp just like they do in sp. So that people who know how to write sp campaign can just make a usualy campaign with 2 or more human sides and call it a mp campaigns without having to think about things like eras or mp_configure.
20150616 16:04:10-!- Greg-Boggs_ is now known as Greg-Boggs
20150616 16:06:14-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 252 seconds]
20150616 16:11:12-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150616 16:15:53-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 246 seconds]
20150616 16:23:04-!- Kwandulin [~Miranda@p5B009F37.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150616 16:32:28-!- gfgtdf [~chatzilla@f054138228.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.5/20150525141253]]
20150616 16:32:55-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20150616 16:48:55-!- cib0 [~cib@p5DC75F4D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150616 16:56:32-!- Kwandulin [~Miranda@p5B009F37.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150616 17:01:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20150616 17:34:53-!- mjs-de [~mjs-de@129.217.43.93] has quit [Remote host closed the connection]
20150616 17:59:29-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150616 18:03:59-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 245 seconds]
20150616 18:16:04-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20150616 18:32:07-!- cib0 [~cib@p5DC75F4D.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150616 18:32:29-!- cib0 [~cib@p5DC75F4D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150616 19:03:44-!- shurnormal [~uxio@unaffiliated/ushiu] has quit [Quit: reboot]
20150616 19:17:21-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150616 19:44:12-!- Kwandulin [~Miranda@p5B009F37.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150616 19:50:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150616 20:15:47-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20150616 20:31:30-!- hay207 [~haythamme@41.34.57.57] has quit [Quit: Leaving]
20150616 20:32:46-!- cib0 [~cib@p5DC75F4D.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150616 20:33:01-!- cib0 [~cib@p5DC75F4D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150616 20:33:11< shadowm> gfgtdf: It's lipkab, not libkap.
20150616 20:33:33< shadowm> It's not lipkap either.
20150616 20:36:41-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20150616 20:37:21< shadowm> Haha, zookeeper was fooled by a spammer.
20150616 20:37:42< zookeeper> nooooooo
20150616 20:37:53< zookeeper> erase my shame
20150616 20:38:15< zookeeper> phew
20150616 20:38:21< zookeeper> you were saying?
20150616 20:54:10-!- [Relic] [~Relic]@2602:306:33a3:6d30:498c:8b73:bbb8:ca9b] has joined #wesnoth-dev
20150616 21:08:05-!- StandYourGround [~Adium@2602:306:83db:de50:f81e:dddc:ed2a:c90f] has joined #wesnoth-dev
20150616 21:08:51-!- StandYourGround [~Adium@2602:306:83db:de50:f81e:dddc:ed2a:c90f] has quit [Client Quit]
20150616 21:17:29-!- Appleman1234_ [~Appleman1@KD106154025019.au-net.ne.jp] has joined #wesnoth-dev
20150616 21:20:41-!- Appleman1234__ [~Appleman1@KD106154014212.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20150616 21:36:06-!- horrowin1 [~Icedove@2a02:810a:8b00:5298:21b:fcff:fee3:c3ff] has quit [Quit: horrowin1]
20150616 21:43:26-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 265 seconds]
20150616 21:44:54-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20150616 21:51:37-!- StandYourGround [~Adium@2602:306:83db:de50:a519:2806:f176:d823] has joined #wesnoth-dev
20150616 21:51:57-!- StandYourGround [~Adium@2602:306:83db:de50:a519:2806:f176:d823] has quit [Client Quit]
20150616 22:34:17-!- cib0 [~cib@p5DC75F4D.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150616 22:34:36-!- cib0 [~cib@p5DC75F4D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150616 22:47:42-!- kex [~kex@31.11.67.182] has quit [Remote host closed the connection]
20150616 22:49:12-!- cib0 [~cib@p5DC75F4D.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds]
20150616 22:53:01-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20150616 23:10:50-!- gfgtdf [~chatzilla@f054138228.adsl.alicedsl.de] has joined #wesnoth-dev
20150616 23:34:30-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20150616 23:43:09-!- kex [~kex@78.157.10.254] has joined #wesnoth-dev
20150616 23:48:03-!- kex [~kex@78.157.10.254] has quit [Remote host closed the connection]
20150616 23:49:52-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20150616 23:58:37< shadowm> gfgtdf: So, those bugs, are they still present?
--- Log closed Wed Jun 17 00:00:21 2015