--- Log opened Sun Oct 07 00:00:58 2018 20181007 00:11:45-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181007 00:19:53<+wesdiscordbot> @Pentarctagon , celticminstrel: The branch doesn't change anything about commits to 1.14 that haven't been fwdported to current master. They'd still need to be fwdported to new master. 20181007 00:22:37<+wesdiscordbot> right, my concern is mostly that there are commits to 1.14 only that were never marked as needing to be forward-ported, whether because it was a fix that wouldn't apply to master with a_r, it was just forgotten, etc. 20181007 00:24:17<+wesdiscordbot> Yeah, there are a couple of things. 1) Commits to 1.14 that haven't been fwdported for whatever reason 2) Issues that have been closed because they were fixed on master, but aren't fixed by the branch 20181007 00:24:35<+wesdiscordbot> Someone will need to go through the 600 commits I outlined in my comment on 3603 20181007 00:29:43<+wesdiscordbot> Is there any reason you guys absolutely must rewrite master instead of just creating a new branch 20181007 00:30:19< celticminstrel> @Vultraz - Mainly for reduced confusion, but it's not absolutely necessary to rewrite master. 20181007 00:30:23< celticminstrel> It's jsut preferred. 20181007 00:30:51<+wesdiscordbot> I would prefer you did not, since it will cause a lot of trouble for people. 20181007 00:31:02<+wesdiscordbot> We can make a new branch and set it as default 20181007 00:31:07< celticminstrel> It will cause a lot of trouble for people both ways. 20181007 00:31:27< celticminstrel> There is no scenario here in which we can avoid creating a lot of trouble for people. 20181007 00:32:05<+wesdiscordbot> what'sthe trouble in the case of a new branch? 20181007 00:32:08< celticminstrel> Also, if we're creating a different branch and setting it as default, I think we should outright delete the master branch. 20181007 00:32:26< celticminstrel> @sevu - Same as if we reuse the master branch, TBH - people need to update all their forks for the new main branch. 20181007 00:32:50<+wesdiscordbot> no? 20181007 00:32:54<+wesdiscordbot> just switch branches 20181007 00:33:04<+wesdiscordbot> as opposed to dealing with a rewrite 20181007 00:33:35< celticminstrel> Either way you need to update any branches you intended to merge to master. 20181007 00:33:58< celticminstrel> And this update is the exact same process regardless of whether we reuse master or create a differently-named branch. 20181007 00:34:15<+wesdiscordbot> That update is the same 20181007 00:34:20<+wesdiscordbot> Yes 20181007 00:34:24< celticminstrel> That's what I said, yes. 20181007 00:35:12<+wesdiscordbot> I meant it causes trouble for people having to pull the changes and deal with a rewrite 20181007 00:35:49< celticminstrel> I'm not opposed to making a new branch and setting it as default, but in that case I think we should delete master as well, so that people don't pull it by accident. 20181007 00:36:16<+wesdiscordbot> leaving the current master named as master would be misleading, yeah 20181007 00:36:17<+wesdiscordbot> Please don't 20181007 00:36:17<+wesdiscordbot> We can add a #error "Don't use this branch" to some cpp file 20181007 00:36:28<+wesdiscordbot> in master, so people don't use it by mistake 20181007 00:36:47< celticminstrel> That seems like a really weird idea... 20181007 00:36:52<+wesdiscordbot> I know my work is going nowhere, but I'd rather it not be thrown in the sea. 20181007 00:36:52< celticminstrel> And why not @Vultraz? 20181007 00:36:58<+wesdiscordbot> isn't* 20181007 00:37:00<+wesdiscordbot> wait 20181007 00:37:01<+wesdiscordbot> no 20181007 00:37:04< celticminstrel> Um Vultraz, I think you missed something. 20181007 00:37:05<+wesdiscordbot> scratch the isn't 20181007 00:37:06<+wesdiscordbot> i can't type 20181007 00:37:34< celticminstrel> Take a look at https://github.com/wesnoth/wesnoth/commits/accelerated-rendering-attempt quickly. 20181007 00:37:44< celticminstrel> I'm not proposing throwing your work in the sea. 20181007 00:37:58<+wesdiscordbot> I see 20181007 00:37:59< celticminstrel> I'm saying we should not have a master branch that is unusable, even if it's not the default branch on GitHub. 20181007 00:38:08< celticminstrel> Because some people might pull without checking. 20181007 00:38:21<+wesdiscordbot> hm 20181007 00:38:27< celticminstrel> And removing the master branch altogether would, I think, give them a more useful error message. 20181007 00:38:38<+wesdiscordbot> All existing clones use master as their branch 20181007 00:38:44<+wesdiscordbot> Changing the default only affects new clones 20181007 00:39:48<+wesdiscordbot> travis would also obviously need an update to uses something other than master 20181007 00:39:52<+wesdiscordbot> appveyor too 20181007 00:39:55<+wesdiscordbot> I assume 20181007 00:39:56<+wesdiscordbot> blaaaaah 20181007 00:40:14< celticminstrel> Of course. 20181007 00:40:27< celticminstrel> (I'm not sure whether josteph's statements are supposed to be in favour of, against, or neutral.) 20181007 00:40:32< celticminstrel> (^-of) 20181007 00:40:42<+wesdiscordbot> Neutral 20181007 00:41:50<+wesdiscordbot> accelerated-rendering-attempt — finally a name which does not sound negative (and it sounds different than the origina a_r branch too) 20181007 00:42:34<+wesdiscordbot> To git, branch names don't really matter, what matters is the commits they point to. The name master is only treated differently in existing clones that have it checked out, and in git or github clients that ignore the "Default branch" setting 20181007 00:52:34< irker521> wesnoth/wesnoth:1.14 Jyrki Vesterinen 07fad7a7b5 Add @JGelfand to credits AppVeyor: All builds passed 20181007 01:42:21< celticminstrel> Can someone please do this https://github.com/wesnoth/wesnoth/pull/3603#issuecomment-427614786 20181007 01:42:44< celticminstrel> I'm not eager to do GitHub things when the site doesn't even work properly on my computer. 20181007 01:43:14< celticminstrel> And by the time I get Windows working again I'll probably have forgotten about this. 20181007 01:52:21<+wesdiscordbot> will this new master branch retain the same c++14 minimum? 20181007 01:52:51<+wesdiscordbot> wait, no, I'm the one who decides that 20181007 01:52:52<+wesdiscordbot> 😬 20181007 01:52:53< celticminstrel> Not sure about C++14, but it does have the VS2015 project update. 20181007 01:53:42<+wesdiscordbot> From memory, there were non-trivial conflicts in unique_ptr/shared_ptr changes (particularly in ai/actions.cpp), boost::thread/std::thread changes, boost filesystem / std::filesystem changes 20181007 01:53:51<+wesdiscordbot> they should be kept 20181007 01:54:03< celticminstrel> The std::filesystem changes shouldn't be, probably. 20181007 01:54:09< celticminstrel> Because that's C++17. 20181007 01:54:27< celticminstrel> std::thread is fine as long as it doesn't break MinGW as it used to. 20181007 01:54:43< celticminstrel> unique vs shared... well I'd have to see it to know. 20181007 01:54:46<+wesdiscordbot> filesystem is conditionally compiled 20181007 01:55:01<+wesdiscordbot> and not functional 20181007 01:55:11< celticminstrel> Which means there's little point in including it anyway. 20181007 01:56:08<+wesdiscordbot> thread we absolutely keep 20181007 01:56:14<+wesdiscordbot> and all the make_unique stuff 20181007 01:56:55< celticminstrel> I have no objection to keeping thread as long as it doesn't break MinGW builds. 20181007 01:57:18< celticminstrel> And at this point in time I have no opinion on the shared/unique question. 20181007 01:57:57< celticminstrel> (FTR, I learned recently that make_unique / make_shared can be slightly better-performant compared to constructing the shared_ptr directly, but I doubt that would matter in most places in Wesnoth.) 20181007 01:58:15<+wesdiscordbot> ya know, I don't like that we don't a consensus on what to do with master. 20181007 01:58:44< celticminstrel> It's not surprising TBH. Consensus is difficult. 20181007 01:59:41<+wesdiscordbot> we can't even decide whether to go with a rolling release model 20181007 02:23:46< irker521> wesnoth/wesnoth:master Jyrki Vesterinen 110bab74f0 Add @JGelfand to credits AppVeyor: All builds passed 20181007 02:33:19-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20181007 02:36:51-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 02:38:27-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit] 20181007 02:53:09< gfgtdf> @Vultraz: is there anyone against the rollign release model ? 20181007 02:55:22< gfgtdf> i strongly support keeping the c++14 mimimum for maste 20181007 02:55:48< celticminstrel> I have no objection to the C++14 minimum TBH. 20181007 02:56:09<+wesdiscordbot> There's one problem which came to mine the last days about the api level idea… 20181007 02:56:29<+wesdiscordbot> it works great for adding new WML tags or similar 20181007 02:56:40<+wesdiscordbot> but what about unit stat changes for balance? 20181007 02:57:08< gfgtdf> sevu: you mean for oos or for sp cpatability ? 20181007 02:57:20< gfgtdf> compatability* 20181007 02:57:36<+wesdiscordbot> for oos 20181007 02:58:27<+wesdiscordbot> rubs eyes fuck 20181007 02:58:34<+wesdiscordbot> yeah that's a good polint 20181007 02:58:46-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 02:58:48< gfgtdf> hmm yes i think unitstat changes cannot go into 1.14., unless we come up with new idea 20181007 02:59:22<+wesdiscordbot> what if we do what celmin wants and bump to 1.x+1 any time we have a feature release. 20181007 02:59:41-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit] 20181007 03:00:18< gfgtdf> celmin didnt say he demands that, he onyl does demands that for brekign changes (like new unit stats) 20181007 03:00:30< gfgtdf> rollign release doesnt mean that we can no longer increase the secodn number 20181007 03:00:50< gfgtdf> just that we will do fully compatibel changes without increasing the secodn number 20181007 03:01:29<+wesdiscordbot> different 1.x series would not be compatible 20181007 03:01:29< gfgtdf> actually i'm quite sure we had that discussion already. 20181007 03:01:35<+wesdiscordbot> but different 1.x.y would be 20181007 03:01:38<+wesdiscordbot> same as now 20181007 03:01:53<+wesdiscordbot> but we can't adopt the proposal to drop the 1 20181007 03:03:07< celticminstrel> Dropping the 1 causes a completely different class of problems. 20181007 03:03:20<+wesdiscordbot> yes 20181007 03:03:34<+wesdiscordbot> but right now it's because all series 1 releases need a unifying prefix 20181007 03:04:04-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 272 seconds] 20181007 03:05:11<+wesdiscordbot> The rolling release model is the best way to go since it allows changes to get out quickly without protracted dev cycles. 20181007 03:05:24<+wesdiscordbot> which will be important if development eventually focuses on series 2 20181007 03:05:41<+wesdiscordbot> inb4 celmin "you don't know series 2 will work out" 20181007 03:06:03< celticminstrel> Even Bitron admitted that, so... 20181007 03:06:19<+wesdiscordbot> faith must be had 20181007 03:08:56< gfgtdf> did you now switch from gdscript compltely to c# for that? 20181007 03:09:33<+wesdiscordbot> i think that's don eyes 20181007 03:14:16< celticminstrel> I have no idea what anyone is talking about anymore. 20181007 03:24:22-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 03:29:01-!- gfgtdf [~Daniel@x4dbbc409.dyn.telefonica.de] has quit [Read error: Connection reset by peer] 20181007 03:59:08-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity] 20181007 04:15:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20181007 04:15:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20181007 04:42:46< irker521> wesnoth/wesnoth:master DisherProject 328a4b7b11 SotBE: Add [show_if] to the objectives t AppVeyor: All builds passed 20181007 04:48:08<+wesdiscordbot> celmin: we decided to use C# instead of GDScript for the W2 prototype 20181007 04:49:19<+wesdiscordbot> It's faster (supposedly) and also a more widely known language 20181007 04:49:42<+wesdiscordbot> Godot 3.0 introduced support for it and they're still refining it 20181007 04:57:47<+wesdiscordbot> @jyrkive You were right for building 1.8, it was due to lua being to new. 1.8 does not bring it's own lua but uses the systems one. I managed to build it, your hint pointed me in the right way. 20181007 06:04:38< celticminstrel> I have no idea what that even means. 20181007 06:05:26< celticminstrel> If you mean you're using C# as a scripting language, my general reaction is "why". 20181007 06:05:51< celticminstrel> C# is not a good scripting language. 20181007 06:06:09< celticminstrel> It's very Java-like, which means lots of boilerplate because everything must be a class. 20181007 06:09:05<+wesdiscordbot> gfgtdf: fwiw, I'm not against the rolling release idea as a whole, but I am against having getting a functional master branch be connected to changing to a rolling release model. I think those are two separate issues, and the problem with master is far more urgent to resolve than changing release models. 20181007 06:09:41<+wesdiscordbot> celticminstrel: C# wouldn't be used for UMC scripting - the preference for that right now would be for lua. 20181007 06:10:18<+wesdiscordbot> C# is being used for the game coding, such as https://github.com/wesnoth/haldric/blob/master/units/Unit.cs 20181007 06:10:23< celticminstrel> Ehhh. 20181007 06:10:38< celticminstrel> That already makes me 80% less enthusiastic about ever contributing to it though. 20181007 06:11:18<+wesdiscordbot> using C# at all, or using lua for UMC scripting? 20181007 06:11:29< celticminstrel> Using C# for the game coding. 20181007 06:13:18<+wesdiscordbot> shrugs If the decision were to use gdscript, I don't know if I'd be contributing anything. Knowing C# at least has some value to me outside of anything wesnoth/godot related, whereas gdscript really doesn't. 20181007 06:14:11< celticminstrel> True, it's definitely better than writing the game code in GDScript. Was that possibility actually seriously considered? 20181007 06:15:25<+wesdiscordbot> Bitron originally wrote the first couple source files in gdscript before converting over after Dave brought up the C# version. Using C# was discussed a bit, and then he rewrote those bits in C#. 20181007 06:16:01< celticminstrel> Huh. 20181007 06:17:34<+wesdiscordbot> the main issues with C# for now being that even they're calling it in an alpha stage, and it still doesn't support iOS largely due to iOS not allowing JITs. They are working on both though, so by the time any 2.0 release would be ready it's more than likely both would be resolved. 20181007 06:18:44< celticminstrel> I mean yes. C# normally runs on a VM, but there's logically no reason you couldn't compile it to avoid that requirement. 20181007 06:19:14< celticminstrel> Didn't Android also do that with Java? I could be misunderstanding something there though. 20181007 06:19:26< celticminstrel> That should be a comma after the yes, 20181007 06:19:48<+wesdiscordbot> according to jyrkive, Unity gets around this by going C# -> C# IL -> C++ -> compiled code. 20181007 06:20:03< celticminstrel> IL? 20181007 06:20:45<+wesdiscordbot> Intermediary Language, ie what they run in the VM 20181007 06:21:45< celticminstrel> Oh, so the equivalent of Java bytecode? 20181007 06:21:46<+wesdiscordbot> https://docs.unity3d.com/Manual/IL2CPP.html 20181007 06:21:50<+wesdiscordbot> right 20181007 06:22:17< celticminstrel> I find it weird then that C++ is an additional intermediary step there. 20181007 06:22:53< celticminstrel> Though I guess Java bytecode, at least, despite being an assembly language of sorts, is quite a bit higher-level than an actual machine language. 20181007 06:23:11<+wesdiscordbot> probably it wouldn't be performant enough otherwise. like the difference between default lua and that luajit proposal. 20181007 06:27:12<+wesdiscordbot> also, for me at least, I already know Java, so C# I could essentially just pick up and start using. 20181007 06:27:30<+wesdiscordbot> so that was another point in its favor for me 20181007 06:32:27< celticminstrel> Well, that's probably true of me too, to be fair. 20181007 06:32:40< celticminstrel> That is, I already know Java too. 20181007 06:32:51< celticminstrel> So I guess I could probably pick up C# quickly if I really wanted to. 20181007 06:33:06< celticminstrel> The question is whether I really want to. 20181007 06:33:24-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20181007 06:35:28<+wesdiscordbot> up to you, obviously. though if you do, I'd hope an IRC bridge is added since I doubt you'll be using Discord. getting more people on board with contributing to 2.0 should be much more important than vultraz's aversion to IRC. 20181007 06:36:36< celticminstrel> Yes, I won't be using Discord. 20181007 06:47:47< irker521> wesnoth/wesnoth:master DisherProject d08391ba27 TRoW S14: Fix sea serpents placement AppVeyor: All builds passed 20181007 07:10:51<+wesdiscordbot> The reason for me to agree on C# was that it would be fairly easy to pick up as I know some Java, and also because it is said to be much faster than GDScript. celticminstrel FYI, GDScript is very much like python and even for non programmers fairly easy to pick up. And there is also NativeScript for Godot, which is a way to use C++ for scripting which is the most work, but also runs the fastest. And NativeScript can be 20181007 07:10:52<+wesdiscordbot> used without recompiling the engine. And finally, there are also Modules. These are also written in C++. They require recompiling the engine but can essentially extend the engine with what ever functionality you like. Also, we could use different languages in different parts. GDScript for lightweight code, C# or C++ for heavy stuff. I also heard now that there is a third party python support, though I haven't seen that yet. So, for 20181007 07:10:52<+wesdiscordbot> those who can't live with C++, there is plenty room for it to be of use. For those who have a C# aversion, there is C++ or GDScript. 20181007 07:15:44<+wesdiscordbot> @Bitron which parts would use gdscript? I was imagining c++ would be for modules and c# for game logic 20181007 07:22:04<+wesdiscordbot> Same as C#, game logic. But even though it it would probably possible to use both, it's best to agree on one, which at the moment is indeed C#. I wouldn't mind using NativeScript (C++) on heavy tasks in game logic to boost up performance though. And Modules are indeed all C++. 20181007 07:24:24<+wesdiscordbot> For "heavy tasks", I'd advise using C# at first, and only rewriting in C++ if it turns out to be necessary. 20181007 07:25:59<+wesdiscordbot> As an eexample, the mobile game I'm developing at work is developed with Unity and uses C# for all scripting. It turned out that the game does have performance issues on most phones... but it's entirely GPU-bound. Optimizing pretty much anything on the CPU side (including the scripts) is useless. 20181007 07:28:50<+wesdiscordbot> That reminds me of Godot's Shader language. That's of course another language that could be of use where C# or C++ can't do much of a difference. IIRC it's similar to GLSL. 20181007 07:30:55<+wesdiscordbot> http://docs.godotengine.org/en/3.0/tutorials/shading/shading_language.html 20181007 07:32:28< celticminstrel> ... 20181007 07:33:43<+wesdiscordbot> If you have something to say, say it. Don't just give us ellipses. 20181007 07:39:25< celticminstrel> Sorry, I was going to say something and then got distracted and forgot. 20181007 07:39:41< celticminstrel> It wasn't anything useful though, just along the lines of "why do they have their own shading language". 20181007 07:41:45<+wesdiscordbot> Cross-platform support, I think. 20181007 07:43:09<+wesdiscordbot> Unity's approach to shaders is that developers write them in HLSL. On platforms which don't support HLSL natively, they're compiled to some other language. 20181007 07:43:49-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20181007 07:45:45-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20181007 07:45:48-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20181007 07:48:56-!- Oebele [~quassel@185-11-201-31.ftth.glasoperator.nl] has joined #wesnoth-dev 20181007 07:53:51<+wesdiscordbot> Godot is supposed to be an easy to use engine. GDScript, as an example, is designed to be quick and easy. I assume this is the same with their shader language. Their shader language does some things for you which you would have to do yourself in plain GLSL. 20181007 07:54:26<+wesdiscordbot> *quick as in quick to write 20181007 08:12:09<+wesdiscordbot> the C++ vs C# bit reminds me of the saying "premature optimization is the root of all evil." 20181007 08:12:31<+wesdiscordbot> which is part of a larger quote, but still pretty true. 20181007 08:30:35<+wesdiscordbot> I'm not a good enough programmer (yet) to make any of these decisions, I just name what comes to my mind because I want you to know what's possble, so we can find something everyone is happy with, or at the very least acceptable for most. 20181007 08:42:08<+wesdiscordbot> fair enough 20181007 09:37:21< irker521> wesnoth/wesnoth:accelerated-rendering-attempt Jyrki Vesterinen 110bab74f0 Add @JGelfand to credits AppVeyor: All builds passed 20181007 10:00:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181007 10:13:14<+wesdiscordbot> I have a comment here from Remi Verschelde, on of the main contributors to Godot. On my request for hands on the prototype in the godot community. Nice! I wish I had time to contribute as Wesnoth is one of my favourite games, but maintaining Gdot itself keeps me busy enough ;) A word of caution on your choice to go with Mono/C# though: the Mono ecosystem is hard to package (especially with MSbuild being virtually 20181007 10:13:15<+wesdiscordbot> impossible to build from only open source components - you need a binary build of an old dotnet to build it on Linux for Mono...), and Godot has high requirements on the Mono version (currently 5.12+). So going with Godot+Mono would mean that potential Godot-powered versions of Wesnoth might have a hard time making their way into Linux distros, many of which are stuck on Mono 4.x today. And the latter have historically been one of 20181007 10:13:15<+wesdiscordbot> the main means of distribution of Wesnoth - it's maybe less relevant today and not a big concern, but worth mentioning anyway. So all in all, if it's just a matter of "programmer's taste", I would advise to at least consider GDScript which makes deployment easier, and a lower barrier to entry for potential contributors (as it's much easier to become fluent in than C#). If there are stronger technical reasons (like the need for 20181007 10:13:16<+wesdiscordbot> some libraries, static typing and various advantages of the C# ecosystem), that's of course a valid choice :) 20181007 10:57:05<+wesdiscordbot> So there's basically no reason to use C# other than making linux packaging harder? 20181007 11:02:03<+wesdiscordbot> Well, first of all, congratulations for making that amazing floss game. As remi mentioned, please consider gdscript before going full C#. I don't think C# export for mobile yet, and surely you would be precluding for a while the web export (which would be awesome in a floss game like that). That said, being responsible for network code of the engine, and a fan of the game myself, I would gladly help you out would you need 20181007 11:02:03<+wesdiscordbot> any help in that. Don't hesitate to contact me on godotengine(s) IRC channels (fales) or here on FB :) They indeed recommend using GDScript over C# most of the time. 20181007 11:03:43<+wesdiscordbot> I suspect the reason for C# backend is mostly to accomodate developers that have used Unity 20181007 11:11:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181007 11:17:56<+wesdiscordbot> I don't mind either of these languages, really. Maybe dave wants to elaborate on why he thinks C# is the better choice? 20181007 11:18:40<+wesdiscordbot> @Denivarius ^^ 20181007 11:33:23<+wesdiscordbot> It wouldn't take too long to port things back to GDScript, if necessary. And if it means getting a few more hands on the prototype, it might weight more than the bonuses C# brings. Which to be honest I'm not sure of, other than slightly better performance. We do use C#'s XMLParser, but GDScript has one as well. (Asuming that Godot's parser works in GDScript, as it didn't in C#) GDScript is also definitely more stable that 20181007 11:33:24<+wesdiscordbot> C# as things are. (Vultraz has/had troubles with Godot Mono crashing randomly). Also, Remi is right, GDScript is really easy to pick up. 20181007 11:42:14< irker521> wesnoth/wesnoth:gui2_help Charles Dang bd00adffd4 Help Browser: don't generate nodes for h AppVeyor: All builds passed 20181007 11:48:19<+wesdiscordbot> There is an article from a guy who developed a game in Godot on why he switched from GDScript to C#. Might be an interesting read. https://cart.codes/post/170375059992/porting-high-hat-from-gdscript-to-csharp 20181007 11:52:29< irker521> wesnoth: gfgtdf wesnoth:1.14 33e1601c9e76 / src/ (6 files in 3 dirs): refactor battle_context https://github.com/wesnoth/wesnoth/commit/33e1601c9e76d9ebcec2a9371baef889646db4ad 20181007 11:52:31< irker521> wesnoth: gfgtdf wesnoth:1.14 1e36906ad197 / src/actions/ (attack.cpp attack.hpp): remove unused cctors https://github.com/wesnoth/wesnoth/commit/1e36906ad197579f9d251f651cade4284fe7028f 20181007 11:52:33< irker521> wesnoth: gfgtdf wesnoth:1.14 189df969b5f7 / src/actions/attack.cpp: add debug info in battle_context https://github.com/wesnoth/wesnoth/commit/189df969b5f76e3fd71ab2fb209a399cd9507b11 20181007 12:28:17-!- travis-ci [~travis-ci@ec2-54-205-154-72.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 12:28:18< travis-ci> gfgtdf/wesnoth#1301 (1.14 - 5f6ee17 : Charles Dang): The build was canceled. 20181007 12:28:18< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438243073 20181007 12:28:20-!- travis-ci [~travis-ci@ec2-54-205-154-72.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 12:49:20-!- Oebele [~quassel@185-11-201-31.ftth.glasoperator.nl] has quit [Remote host closed the connection] 20181007 12:49:23-!- travis-ci [~travis-ci@ec2-184-73-17-136.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 12:49:24< travis-ci> gfgtdf/wesnoth#1302 (1.14 - b15c19b : gfgtdf): The build was canceled. 20181007 12:49:24< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438248186 20181007 12:49:24-!- travis-ci [~travis-ci@ec2-184-73-17-136.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 13:38:26-!- travis-ci [~travis-ci@ec2-54-205-154-72.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 13:38:26< travis-ci> gfgtdf/wesnoth#1303 (1.14 - de7f10e : gfgtdf): The build passed. 20181007 13:38:27< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438251151 20181007 13:38:27-!- travis-ci [~travis-ci@ec2-54-205-154-72.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 13:44:20< irker521> wesnoth: Charles Dang wesnoth:1.14 57070f230408 / src/ (10 files in 3 dirs): Saved Game: reame "starting pos" to "starting point" to avoid confusion https://github.com/wesnoth/wesnoth/commit/57070f230408532089a7af70f2b28badf1c96a01 20181007 13:44:23< irker521> wesnoth: Charles Dang wesnoth:1.14 e23a95c287a8 / src/ (8 files in 7 dirs): Used std::string::front() and back() in more places https://github.com/wesnoth/wesnoth/commit/e23a95c287a8a477cc35c248034201154da6603b 20181007 13:44:26< irker521> wesnoth: gfgtdf wesnoth:1.14 ea611b52d756 / src/formula/function.cpp: fix out of bonunds check https://github.com/wesnoth/wesnoth/commit/ea611b52d756d4400b07fcdfc100799247883612 20181007 13:44:28< irker521> wesnoth: Charles Dang wesnoth:1.14 fc6ff0c25d58 / src/ (13 files in 9 dirs): Cleaned up unnecessary instances of emplace_back(config {}) https://github.com/wesnoth/wesnoth/commit/fc6ff0c25d58c6486eb1f796fe88c39602a2287c 20181007 13:44:31< irker521> wesnoth: Charles Dang wesnoth:1.14 ecaef55d0c64 / src/units/animation.cpp: Unit/Animation: emplace_back (mostly) ahoy https://github.com/wesnoth/wesnoth/commit/ecaef55d0c64145bffc4ce9522ed860a0d7f98d4 20181007 13:44:34< irker521> wesnoth: Charles Dang wesnoth:1.14 3d953aa2f051 / src/ (6 files in 6 dirs): Used UNUSED macro instead of (void) where applicable https://github.com/wesnoth/wesnoth/commit/3d953aa2f051cb694ac0e1f1b07570444c27bb04 20181007 13:44:37< irker521> wesnoth: Charles Dang wesnoth:1.14 d60da99b5f12 / src/ai/ (6 files in 2 dirs): AI: deployed std::make_shared in a whole bunch of places https://github.com/wesnoth/wesnoth/commit/d60da99b5f12c1e0155069e5a87aa10803fbe783 20181007 13:44:40< irker521> wesnoth: Charles Dang wesnoth:1.14 f6372830c1c4 / src/ (11 files in 7 dirs): Deployed std::make_shared in more places https://github.com/wesnoth/wesnoth/commit/f6372830c1c4a9e909ced547f51a9d39eeae41c7 20181007 13:44:43< irker521> wesnoth: Charles Dang wesnoth:1.14 90518b645ca0 / src/gui/ (64 files in 2 dirs): GUI2: added a public static type getter to all widgets implementing get_control_ https://github.com/wesnoth/wesnoth/commit/90518b645ca08f832f2ff01d817bd87b43ec23ce 20181007 13:46:58<+wesdiscordbot> 👍 20181007 13:55:42-!- gfgtdf [~Daniel@x55b26302.dyn.telefonica.de] has joined #wesnoth-dev 20181007 13:56:44< gfgtdf> any opinon on whether to bacckport "Removal of openmp" ? I mean is there any case where it openmp gave us soemthing important, and how was the removal of openmp related to ar ? 20181007 13:59:13<+wesdiscordbot> gfgtdf: we decided it wasn't necessary to have anymore since from the sound of it it barely offered anything when it was first implemented due to bad benchmarks and/or benchmarks being given too much weight 20181007 13:59:50<+wesdiscordbot> I don't think it had anything to do with ar specifically beyond certain bits of code that had OMP directives being changed and/or removed 20181007 14:00:45< gfgtdf> ok 20181007 14:15:08-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 14:23:08-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20181007 14:23:14-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20181007 14:25:09-!- hyp3rbor3ax [~hyp3rbor3@p57B390E2.dip0.t-ipconnect.de] has joined #wesnoth-dev 20181007 14:43:18-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20181007 15:01:05< irker521> wesnoth/wesnoth:1.14 nemaara f62020ed93 S7: minor update to troll speech AppVeyor: All builds passed 20181007 15:39:14-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 15:59:10-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20181007 16:19:17< zookeeper> it wasn't easy to get a plasma twirl to tile smoothly on a hex grid, but i guess i could do those too if we needed it... for some reason that i can't think of right now: https://www.dropbox.com/s/3pq1i80jmikftrk/spinning_plasma_demo.png?dl=0 (didn't bother animating yet) 20181007 16:22:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181007 16:33:11< irker521> wesnoth/wesnoth:1.14 newfrenchy83 11623c35bf Update README.md AppVeyor: All builds passed 20181007 17:14:49-!- travis-ci [~travis-ci@ec2-54-211-94-52.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 17:14:50< travis-ci> gfgtdf/wesnoth#1306 (1.14 - acc2500 : Charles Dang): The build was broken. 20181007 17:14:50< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438310758 20181007 17:14:50-!- travis-ci [~travis-ci@ec2-54-211-94-52.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 17:22:16-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20181007 17:22:22-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20181007 17:37:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181007 17:39:01-!- travis-ci [~travis-ci@ec2-54-82-79-200.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 17:39:02< travis-ci> gfgtdf/wesnoth#1307 (1.14 - 9610fe2 : gfgtdf): The build is still failing. 20181007 17:39:02< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438316793 20181007 17:39:02-!- travis-ci [~travis-ci@ec2-54-82-79-200.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 18:20:00-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20181007 18:26:50-!- travis-ci [~travis-ci@ec2-184-73-17-136.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 18:26:51< travis-ci> gfgtdf/wesnoth#1308 (1.14 - 42c8988 : gfgtdf): The build is still failing. 20181007 18:26:51< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438324396 20181007 18:26:51-!- travis-ci [~travis-ci@ec2-184-73-17-136.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 18:35:04-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20181007 18:35:10-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20181007 18:36:31<+wesdiscordbot> @Vultraz I had tried to keep the boost::thread removal, but it broke test_gui2 20181007 18:38:10<+wesdiscordbot> @Vultraz The lexical_caster stuff I also had to revert because it broke the build (some place called the function with a char argument). 20181007 18:39:10<+wesdiscordbot> @Vultraz All of them can be added back 20181007 18:49:36-!- travis-ci [~travis-ci@ec2-54-227-61-0.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 18:49:37< travis-ci> gfgtdf/wesnoth#1309 (1.14 - 3f3fbd5 : gfgtdf): The build is still failing. 20181007 18:49:37< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438330908 20181007 18:49:37-!- travis-ci [~travis-ci@ec2-54-227-61-0.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 18:56:13< gfgtdf> @josteph was 1749de1521b lost or am i mistaking when the diff ? 20181007 18:56:54<+wesdiscordbot> gfgtdf, I kept the function in the file it was originally in 20181007 18:58:03< gfgtdf> fora specific reason ? It sureley makes sense to have the function defined the file that matches the hpp file where it was declared 20181007 18:59:54<+wesdiscordbot> gfgtdf, I might've been a bit overzealous in this case 20181007 19:02:51< gfgtdf> hm k 20181007 19:06:24-!- josteph [~josteph@wesnoth/developer/josteph] has joined #wesnoth-dev 20181007 19:06:59-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20181007 19:09:14<+wesdiscordbot> gfgtdf, In recruitment.cpp the only diff I see is two return lines, when I diff remaster to master 20181007 19:09:37-!- travis-ci [~travis-ci@ec2-54-227-61-0.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 19:09:38< travis-ci> gfgtdf/wesnoth#1310 (1.14 - be03a34 : gfgtdf): The build is still failing. 20181007 19:09:38< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438340249 20181007 19:09:38-!- travis-ci [~travis-ci@ec2-54-227-61-0.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 19:09:53<+wesdiscordbot> Why do we get these travis notifications here by the way? 20181007 19:10:25-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 19:10:58<+wesdiscordbot> Travis CI configuration is set to send notifications to #wesnoth-dev in Freenode, and gfgtdf hasn't bothered to change the channel for his fork. 20181007 19:13:02< gfgtdf> that was a 1.14 only commit i think. (i compares remaster to 1.14) 20181007 19:13:26< gfgtdf> i woldnt even know how to do that 20181007 19:13:28< gfgtdf> wouldn't 20181007 19:14:12< gfgtdf> i mena without ganign my wesnoth fork itself (i i did that that change woudl be puches to wesnoth ony my next push ) 20181007 19:14:29< gfgtdf> changing* 20181007 19:14:56< josteph> gfgtdf, the branch is expected to be identical _to master_ 20181007 19:15:09< josteph> It's completely expected that stuff that hasn't been fwdported would be absent 20181007 19:15:31< josteph> It's good to note what should be fwdported, of course. 20181007 19:15:53< gfgtdf> yes i know 20181007 19:16:14< josteph> thanks 20181007 19:16:28< josteph> About travis can you just disable travis integration in "Settings" of your fork ? 20181007 19:17:13< gfgtdf> i want travis integration, what i dont want is the messagew to show here 20181007 19:18:31-!- travis-ci [~travis-ci@ec2-54-227-61-0.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 19:18:31< travis-ci> gfgtdf/wesnoth#1311 (1.14 - 337517c : gfgtdf): The build is still failing. 20181007 19:18:32< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438343465 20181007 19:18:32-!- travis-ci [~travis-ci@ec2-54-227-61-0.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 19:19:10<+wesdiscordbot> remove https://github.com/wesnoth/wesnoth/blob/master/.travis.yml#L46-L55 20181007 19:20:42< gfgtdf> changes i do to my branch will be put in the the main repo as soon as i push 20181007 19:21:26< josteph> can't you rebase them before pushing to wesnoth/wesnoth ? 20181007 19:22:10< gfgtdf> i won't do a rebase before every push just becasue of that 20181007 19:22:38-!- hyp3rbor3ax [~hyp3rbor3@p57B390E2.dip0.t-ipconnect.de] has quit [Quit: Leaving] 20181007 19:22:55<+wesdiscordbot> couldn't you just make that single change to .travis.yml in its own commit, then drop that commit before pushing to the main wesnoth repo? 20181007 19:23:35< josteph> can we fix this by logging in to travis as wesnoth and changing some settings ? 20181007 19:24:18< gfgtdf> the settign afaik onyl allow to change environment varialbes, if we can change tr travis script onyl to do these notificatiosn when a certain environment variable is set /no set that woudl work 20181007 19:24:31< gfgtdf> s/tr/the 20181007 19:24:37<+wesdiscordbot> I don't think so. I did check some time back and it didn't seem to be possible. 20181007 19:24:49<+wesdiscordbot> might've changed in the mean time though 20181007 19:25:16<+wesdiscordbot> You should be able to disable those notifications easily. 20181007 19:25:35<+wesdiscordbot> In our account, Travis CI is only monitoring wesnoth/wesnoth. Not forks. 20181007 19:25:44<+wesdiscordbot> It's your own account that monitors your repo. 20181007 19:26:50< gfgtdf> i wond nothign in the travis settings (https://travis-ci.org/gfgtdf/wesnoth/settings) if you want to lok see https://travis-ci.org/wesnoth/wesnoth/settings, should have te same options 20181007 19:28:33<+wesdiscordbot> Go to https://travis-ci.org/profile/gfgtdf and disable integration with the wesnoth repository. 20181007 19:29:02< gfgtdf> i _want_ integration i use integration to check whetehr my stuff works, for the thing i do in my poro before they become prs 20181007 19:29:54< gfgtdf> this is about keeping integration while not showing notifications about them here in this channel. 20181007 19:30:45<+wesdiscordbot> Sounds like you should bite the bullet and rebase before every commit, then. 20181007 19:31:14<+wesdiscordbot> Otherwise the notifications for wesnoth/wesnoth will be lost in the noise. 20181007 19:33:05< gfgtdf> no, really not gonna happen, too much work. Another try woudl be, which would only, work for you discord people though is to make the ircbride ignore those messages from gfgtdf/wesnot 20181007 19:34:23-!- irker521 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20181007 19:34:49< gfgtdf> actuall other users seems to have some kind of solution for similaar issue https://github.com/mozilla/build-tools/commit/c13a2978e0869219295013eeb52cf52227ab45ec 20181007 19:34:50<+wesdiscordbot> It's too much work to do git rebase -i origin/master and delete one line before pushing? 20181007 19:35:16< gfgtdf> yes, if i ahve to do this before every push , and then readd it 20181007 19:35:49<+wesdiscordbot> Mozilla's solution is to ourright block forks from sending notifications to the same channel. 20181007 19:36:28<+wesdiscordbot> If the owner of any fork wants to enable Travis CI integration, they have to configure a different channel. 20181007 19:36:50-!- travis-ci [~travis-ci@ec2-54-197-132-32.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 19:36:51< travis-ci> gfgtdf/wesnoth#1312 (1.14 - a3ea04f : gfgtdf): The build is still failing. 20181007 19:36:51< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438348032 20181007 19:36:51-!- travis-ci [~travis-ci@ec2-54-197-132-32.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 19:36:51<+wesdiscordbot> Seems good enough. 20181007 19:37:57<+wesdiscordbot> gui2 question. Is there a way to implement a collapsible section now? I can think of a checkbutton that hides/unhides a panel. Can anyone think of a reason why this won't work? 20181007 19:39:26<+wesdiscordbot> Just make sure that you set its visibility to "invisible" (sets size to zero), not "hidden" (retains size). 20181007 19:40:03<+wesdiscordbot> It reminds me of https://github.com/wesnoth/wesnoth/commit/8000a868286d374d39c71215de6f376a31e4fe0a but I don't even know if lua is involved in your setting. 20181007 19:40:43< josteph> gfgtdf, So could you look up into patching wesnoth/wesnoth travis.yml like mozilla does? 20181007 19:41:10< gfgtdf> i'll try but i don't nw too mcuh abou these things 20181007 19:41:34< josteph> much appreciated. 20181007 19:41:53< josteph> if you don't figure it out let us know and someone else can take a look. 20181007 19:42:52< celticminstrel> @sinda Off the top of my head the only thing I can think of is to use a tree-view, which is a bit of overkill but is probably possible to make work. 20181007 19:43:33< celticminstrel> I expect you can also get something working by manually showing or hiding it like Jyrki said. 20181007 19:49:37-!- irker611 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20181007 19:49:37< irker611> wesnoth/wesnoth:1.14 Charles Dang 90518b645c GUI2: added a public static type getter AppVeyor: All builds passed 20181007 19:51:33< josteph> in THoT S4 my statistics for S3 count each recall twice, does anyone else see that? 20181007 19:51:58< josteph> For example it says I recalled two Gryphon Riders, actually I recalled just one 20181007 19:53:12< zookeeper> what does it say if/when you haven't yet recalled anyone? 20181007 19:53:48< josteph> what? 20181007 19:53:55< josteph> I'm in S4 and I'm looking at the statistics of S3 20181007 19:54:07< zookeeper> oh. duh. i misread. 20181007 19:54:14< josteph> np 20181007 19:56:06< josteph> recruits are also affected, but advances are not 20181007 19:59:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181007 20:03:16<+wesdiscordbot> Good, thanks. 20181007 20:05:13-!- josteph [~josteph@wesnoth/developer/josteph] has quit [Quit: josteph] 20181007 20:13:49< gfgtdf> about the ircmessage: it seems like you have to install travis tool to a local computer which again requires a programm called 'gem'. I am not even sure whether all involved programms even work on windows though sicne all examples i foudn seem to use linux. 20181007 20:14:21<+wesdiscordbot> gem is Ruby's package management tool. 20181007 20:14:38<+wesdiscordbot> Ruby is cross-platform, everything there should work on Windows. 20181007 20:23:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20181007 20:23:47-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20181007 20:34:43-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20181007 20:35:06-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 20:40:31-!- travis-ci [~travis-ci@ec2-54-159-177-3.compute-1.amazonaws.com] has joined #wesnoth-dev 20181007 20:40:32< travis-ci> gfgtdf/wesnoth#1313 (1.14 - c1ef14a : gfgtdf): The build was fixed. 20181007 20:40:32< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth/builds/438360615 20181007 20:40:32-!- travis-ci [~travis-ci@ec2-54-159-177-3.compute-1.amazonaws.com] has left #wesnoth-dev [] 20181007 20:53:31< irker611> wesnoth: gfgtdf wesnoth:1.14 d6ab780ce94d / .travis.yml: don't show travis notifications from forks https://github.com/wesnoth/wesnoth/commit/d6ab780ce94df14a6eb1eeb4df7ce2543fc27069 20181007 20:53:38< gfgtdf> ok hopefully this works 20181007 20:54:39< irker611> wesnoth: gfgtdf wesnoth:1.14 55bc62f442da / .travis.yml: fixup don't show travis notifications from forks https://github.com/wesnoth/wesnoth/commit/55bc62f442da47f0b754ed9b75238c5a53fd76dd 20181007 21:17:21-!- hyp3rbor3ax [~hyp3rbor3@p57B390E2.dip0.t-ipconnect.de] has joined #wesnoth-dev 20181007 21:19:44-!- hyp3rbor3ax [~hyp3rbor3@p57B390E2.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 20181007 21:39:31-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20181007 21:39:37-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20181007 22:07:08-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20181007 22:07:14-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20181007 22:12:22< irker611> wesnoth/wesnoth:1.14 newfrenchy83 371c4093d1 Update libraries.md AppVeyor: All builds passed 20181007 22:14:27-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20181007 22:14:58-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 22:15:13-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit] 20181007 22:15:35-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 22:16:00-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit] 20181007 22:16:21-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 22:16:46-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit] 20181007 22:17:10-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 22:17:32-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit] 20181007 22:17:59-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20181007 22:18:18-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit] 20181007 22:51:21-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 252 seconds] 20181007 23:01:37-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20181007 23:02:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181007 23:09:22-!- gfgtdf [~Daniel@x55b26302.dyn.telefonica.de] has quit [Quit: Leaving] 20181007 23:31:14-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Read error: Connection reset by peer] 20181007 23:32:09-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev --- Log closed Mon Oct 08 00:00:59 2018