--- Log opened Wed Sep 19 00:00:56 2018 20180919 00:04:03<+wesdiscordbot> having the tod colors smoothly fade from one to another instead of a sudden switch 20180919 00:58:21-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180919 00:58:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180919 01:09:49-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180919 01:09:55-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180919 01:16:55-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has quit [Ping timeout: 244 seconds] 20180919 01:26:43<+wesdiscordbot> well you can actually do that? 20180919 01:26:51<+wesdiscordbot> using color adjust 20180919 01:27:09<+wesdiscordbot> kind of hacky, I guess 20180919 01:58:05-!- irker212 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20180919 02:03:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180919 02:03:13-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180919 05:06:27<+wesdiscordbot> Next time people ask why I always complain about Wesnoth's engine and WML being inflexible af when trying to do anything that mainline doesn't do already, fancy screen effects in particular, I should show them this: https://gist.github.com/shikadiqueen/2ba8faeb4562f3b1694e6ad0eb5855d0 20180919 05:06:55<+wesdiscordbot> That's how much it codes to take to implement a patch of fog fading out simultaneously with a unit fading in. 20180919 05:08:50<+wesdiscordbot> Does it seem straightforward at all to someone who doesn't know that the terrain engine is just the way it is and that there's no way to play simultaneous animations without resorting to ugly hacks like a ginormous premade fog patch graphic displayed as part of a unit animation on layer 1000 or whatever? 20180919 05:09:37<+wesdiscordbot> (Also there's a third animation playing at the same time.) 20180919 05:10:22<+wesdiscordbot> I wish devs took this kind of thing into consideration before taking pragmatic-looking (but dogmatic at the core) stances with regards to Wesnoth's design. 20180919 05:11:44<+wesdiscordbot> I wish I could just say 20180919 05:12:07<+wesdiscordbot> "here's a THING A, here's a THING B, here's a THING C" 20180919 05:12:28<+wesdiscordbot> "A and B start at full opacity, C starts at 0 opacity (bars included since it's a unit)" 20180919 05:12:54<+wesdiscordbot> "by 2.5 seconds into the timeline A and B should be at 0 opacity, C should be at full opacity, now go" 20180919 05:13:50<+wesdiscordbot> Without having to explicitly hog up the display engine for 2.5 seconds to perform every single step using hand-rolled client code. 20180919 05:14:06< celticminstrel> Isn't this literally how the unit animations already work? That's only for a single unit though so it doesn't really help here. 20180919 05:14:22<+wesdiscordbot> What is? 20180919 05:14:39< celticminstrel> Your quoted text. 20180919 05:14:44<+wesdiscordbot> Unit animations do have a timeline (which is flimsy as hell if you've ever run into situations where more than unit participates). 20180919 05:15:09<+wesdiscordbot> "and that there's no way to play simultaneous animations without resorting to ugly hacks like a ginormous premade fog patch graphic displayed as part of a unit animation on layer 1000 or whatever?" 20180919 05:16:00<+wesdiscordbot> Also noting that the boilerplate to make a unit start invisible is crummy af. 20180919 05:16:19<+wesdiscordbot> If the unit is only ever used in that context you're fine and you can use a recruiting animation and [unit] animate=yes. 20180919 05:16:41<+wesdiscordbot> If not then you need a separate unit variation for that special case and give it a recruiting animation. 20180919 05:16:52<+wesdiscordbot> This is called a "clever hack". 20180919 05:17:14<+wesdiscordbot> In practice it's a recipe for unmaintainability. 20180919 05:17:29< celticminstrel> A clever hack is still a hack. 20180919 05:17:40<+wesdiscordbot> And that's not a good thing. 20180919 05:17:45< celticminstrel> Right. 20180919 05:17:50<+wesdiscordbot> That's what I'm trying to get at. 20180919 05:18:07<+wesdiscordbot> did you see my post, celmin? 20180919 05:18:14< celticminstrel> I wasn't really trying to contradict anything you said. 20180919 05:18:18< celticminstrel> I don't think so Vultraz. 20180919 05:18:24< celticminstrel> I was just about to go to bed actually. 20180919 05:18:30<+wesdiscordbot> We do a lot with Wesnoth engine in spite of its limitations... and that requires us to come up with ridiculously oblique tricks that are liable to break at a moment's notice. 20180919 05:18:53<+wesdiscordbot> And that people might need hours or even days to try to understand after the fact. 20180919 05:19:30<+wesdiscordbot> I mean I have a massive thorn on my side later on that I haven't still addressed because it requires unraveling the most convoluted WML I've ever written to try to find the exact spot where Wesnoth 1.14's behaviour diverges from 1.12. 20180919 05:20:29<+wesdiscordbot> And it's exactly because of that that I'm not going to get help from the mainline devs with that. 20180919 05:20:54<+wesdiscordbot> No-one takes well to being handed a ball of code that not even the author herself understands anymore and being told to find out why it doesn't work correctly anymore. 20180919 05:21:32<+wesdiscordbot> And why do these changes in API semantics happen? 20180919 05:21:50<+wesdiscordbot> Because the game engine wasn't designed the Right Way™ from the get go. 20180919 05:22:50< celticminstrel> Well, if there's something you wanted me to see Vultraz, feel free to point me to it tomorrow. I'm going to bed now. 20180919 05:22:54<+wesdiscordbot> And people have spent literally a decade trying to fix other people's mistakes to try to achieve the Right Way™ design. 20180919 05:22:57<+wesdiscordbot> And it's still ongoing. 20180919 05:23:02-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20180919 05:23:40<+wesdiscordbot> celmin: https://forums.wesnoth.org/viewtopic.php?f=2&t=48837 20180919 05:24:13<+wesdiscordbot> I mean I'm sorry for devs who like tinkering with code forever at the expense of their users, but no-one in their right mind would hear this story and tell you "yeah Wesnoth is clearly correctly designed, idk what you're whining about". 20180919 05:24:28<+wesdiscordbot> indeed. 20180919 05:25:05<+wesdiscordbot> And I said this before to the mods but the devs also signed up for a de facto responsibility with the community the moment they became API providers. 20180919 05:25:32<+wesdiscordbot> Wesnoth isn't just a static, unchanging game. It's an engine and a framework with which we develop our content. 20180919 05:25:56<+wesdiscordbot> And its limitations become too evident if you start to write things more complicated than the average cookie-cutter mainline campaign. 20180919 05:26:09<+wesdiscordbot> Just ask people like inferno8 or Dugi if you think I'm being irrational. 20180919 05:26:23<+wesdiscordbot> If I'm being honest, thinking abiut how inferno8 had to hack together animated cutscenes with individual images displays by godknows what method is just.... 20180919 05:26:31<+wesdiscordbot> despairing 😐 20180919 05:26:51<+wesdiscordbot> we're not in goddamn 1980 20180919 05:28:01<+wesdiscordbot> A rewrite is a huge project yes, but we're honestly lying to ourselves if we can't admit it's a good idea. 20180919 05:28:40<+wesdiscordbot> anyway, at dave and jet's suggestion I'm downloading the Godot engine off steam to take a look at it. 20180919 05:29:52<+wesdiscordbot> And everyone likes lying to themselves and claiming that Wesnoth scales well to what it has become -- except the original author himself has admitted on several occasions that Wesnoth was never designed for what it has become and pointed out several mistakes that he's realized in hindsight after 10 years of industry experience beyond Wesnoth. 20180919 05:30:51<+wesdiscordbot> It's not even a case of people trying to defend what someone perceives as their own masterpiece, because Dave has been very clear about the faults in Wesnoth's design. 20180919 05:31:11<+wesdiscordbot> It's just that he addressed them by abandoning ship and going away to do his own thing. 20180919 05:32:04<+wesdiscordbot> And that's what several key mainline devs have done over time, whether they came to that concrete epiphany or just got burnt out from having to do constant duct tape fixes. 20180919 05:32:56<+wesdiscordbot> It's a Sisyphean task at this point trying to plaster over the gaps - nah, maws 20180919 05:49:53-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev 20180919 05:59:58<+wesdiscordbot> if the intent is to move Wesnoth to an engine that's properly designed for what it should be, probably the sooner, the better 20180919 06:11:02<+wesdiscordbot> it would be good to know how many current developers will stay around if godot does end up being used though. C# at least is something I could help out with more, but if the rest of the current dev team ends up not wanting to change over then that's another potential problem. 20180919 06:12:00<+wesdiscordbot> That sounds amazing! Difficult to make a Herculean understatement, but cool! Seeing wesnoth running on a new engine, opening up possibilities for new stuff 20180919 06:12:38<+wesdiscordbot> For me, getting C++ experience is the primary reason of helping this project. It's one reason why I'm not going to help with a rewrite. 20180919 06:19:47-!- vn971 [~vasya@94.158.103.15] has joined #wesnoth-dev 20180919 06:28:30< galegosimpatico> Didn't know (or maybe remember) the Time of Day acronym, but google helped with that. 20180919 06:29:46< galegosimpatico> I couldn't help wedging Terms of Defeat in mistake. D: 20180919 06:30:39<+wesdiscordbot> godot does apparently allow using c++ as well, fwiw 20180919 06:32:57-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180919 06:46:17< aeth> Moving to $engine won't fix WML, though. You'd have to port WML for compatibility and a lot of the ugliness is in WML. 20180919 06:47:47< aeth> WML is a fine configuration language that somehow turned into a programming language that does everything wrong from a programming language design perspective. 20180919 06:48:27<+wesdiscordbot> Agreed. From the start, it was designed to be a markup language, not a programming language. It fits very poorly for scripting. 20180919 06:48:46< aeth> And it has a very confusing conditional system because they're not expressions iirc. 20180919 06:49:06< aeth> Unfortunately even in Lua you often have to write WML tables with that conditional system. 20180919 06:49:53< galegosimpatico> Surely they are implicitly proposing not to port WML to a 2.0 branch or repo. 20180919 06:50:31<+wesdiscordbot> Well, that's trading one problem for another. It would mean rewriting every campaign that 2.0 ships with. 20180919 06:50:58< aeth> It would probably just be better to deprecate or replace the scripting parts and keep everything else. 20180919 06:51:22< galegosimpatico> Yes, I've been thinking that any option is bad. 20180919 06:53:58< galegosimpatico> Fortunately there are enough hands to keep Linux support of wesnoth 1.14 for years until SDL2 becomes legacy. 20180919 07:12:17<+wesdiscordbot> Seems like a great opportunity to get rid of the dead weight. 20180919 07:12:59<+wesdiscordbot> Also no-one said that the campaigns have to be all back at the same time. 20180919 07:16:56<+wesdiscordbot> one thing I am curious about is how UMC would be supported. 20180919 07:17:54<+wesdiscordbot> My first reaction was "you are crazy"; but the more I think about it, the more reasonable it seems. I just worry that if this endeavour fails, Wesnoth is going to still be stuck on 1.14. 20180919 07:17:56-!- vn971 [~vasya@94.158.103.15] has left #wesnoth-dev ["Leaving."] 20180919 07:18:13<+wesdiscordbot> would everyone need to use C#/GDScript now, or what? 20180919 07:30:56<+wesdiscordbot> and yeah, my assumption, if godot does end up being used, is that 1.15.0 would have many fewer features and less content than currently, and a lot of 1.15.x would be rewriting all the current scenarios/campaigns into godot. 20180919 07:32:41<+wesdiscordbot> I'm not a fan of C# myself 20180919 07:55:06<+wesdiscordbot> All questions we’d need to look into. I like Dave and jet’s suggestion to try and get a prototype working before making a final decision 20180919 07:56:04<+wesdiscordbot> What would be the goal for the prototype? Porting over one scenario from 1.14? 20180919 07:56:55<+wesdiscordbot> Sounds reasonable, yes. 20180919 08:00:43<+wesdiscordbot> Godo even already has a hex map demo. 20180919 08:00:43<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/491881308746678282/godot_hex_map.JPG 20180919 08:19:02-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity] 20180919 08:55:18< Soliton> if you want to abandon the current code and move to a new engine just make a new game. unless you want to seriously commit to a smooth transition path for current wesnoth content (which seems unlikely to be feasable or a good idea). 20180919 10:08:14< loonycyborg> I think smooth transition might still work 20180919 10:09:05< loonycyborg> like we still can keep wml scripting and stuff 20180919 10:10:40<+wesdiscordbot> would new engine mean we get stuff like true ranged attacks ? 20180919 10:11:44<+wesdiscordbot> New engine not new game rules 20180919 10:12:04<+wesdiscordbot> If we wanted true ranged attacks we could do it in the current engine (and in fact I'm pretty sure most or all of the support is already there since 1.12) 20180919 10:19:03<+wesdiscordbot> @Lucipurr Acctualy we already have eras with "true ranged attacks". 20180919 10:20:42<+wesdiscordbot> what support ? never seen 20180919 10:21:23<+wesdiscordbot> Engine support 20180919 10:21:32<+wesdiscordbot> I'm assuming 😄 20180919 10:21:57<+wesdiscordbot> so something the end user cant make use of 20180919 10:21:59<+wesdiscordbot> ? 20180919 10:22:39<+wesdiscordbot> Sounds more like t he opposite 🙂 20180919 10:22:58<+wesdiscordbot> Esp. since Hejnewar mentioned eras that has it, already, just above 20180919 10:23:10<+wesdiscordbot> It's for WML authors, not end users, obviously. 20180919 10:23:28<+wesdiscordbot> Players do not have the power to change the rules of the games but content authors do. 20180919 10:23:29<+wesdiscordbot> https://github.com/wesnoth/wesnoth/commit/549a29a4fe3f8f3d44224a0b644479b9501059bb 20180919 10:24:23<+wesdiscordbot> (The attack logic does make use of these in some way but I've never had the chance to see them in the wild since I'm kind of a vanilla person myself.) 20180919 10:28:28<+wesdiscordbot> so ive gone ahead and put min_range=1 max_range=2 into bowman's bow attack to see how it would work and no difference. 20180919 10:32:32<+wesdiscordbot> setting both to 2 caused bow attack to become not usable as can only attack adjacent unit 20180919 10:48:49<+wesdiscordbot> seems that attribute is used to determine which attack can retaliate against which by assigning it an range number, apparently does not have anything to do with "multihex range" 20180919 10:50:22<+wesdiscordbot> That's not true. There is code to support attacks from a distance. 20180919 10:50:23<+wesdiscordbot> https://github.com/wesnoth/wesnoth/blob/1.14/src/actions/attack.cpp#L140-L144 20180919 10:50:43<+wesdiscordbot> IIRC, the case is that the engine supports such attacks, but the UI does not. 20180919 10:51:23<+wesdiscordbot> And multi-hex attacks can be manually triggered from WML. 20180919 10:53:09<+wesdiscordbot> I know, ranged attacks mod does it via right-click menu, if can do without having to invoke the right-click menu each time that'd be great. So its the UI missing, hmm... 20180919 10:53:48<+wesdiscordbot> I think a pull request for that would be welcome. 20180919 11:03:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180919 11:03:47-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180919 11:28:47<+wesdiscordbot> BTW, would like to reiterate that even if we do decide to make a wesnoth 2.0, 1.14 will still remain available. 20180919 11:28:58<+wesdiscordbot> getting rid of it would be a bad idea 20180919 11:47:38< Soliton> s/a bad idea/obviously impossible/ 20180919 11:56:49<+wesdiscordbot> smh... 20180919 12:37:18-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180919 12:37:24-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180919 12:41:18-!- irker100 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20180919 12:41:18< irker100> wesnoth/wesnoth:master V N 5a3b639205 prevent double execution of on_event.lua AppVeyor: All builds passed 20180919 12:44:18-!- behalebabo [~behalebab@unaffiliated/behalebabo] has quit [Ping timeout: 264 seconds] 20180919 12:45:03-!- behalebabo [~behalebab@unaffiliated/behalebabo] has joined #wesnoth-dev 20180919 13:38:11-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180919 13:38:24-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180919 13:56:46-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180919 13:56:52-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180919 15:18:35< Soliton> looks like simple_wml does not serialize correctly and just puts double quotes around the value. thus if the value contains a double quote it will not be correctly deserialized again. 20180919 15:19:24<+wesdiscordbot> Simple_wml is designed to handle only a subset of the cases the full WML implementation supports. 20180919 15:19:34<+wesdiscordbot> Is there a need for duoble quotes somewhere? 20180919 15:20:09< Soliton> you can have double quotes in any value, sure. 20180919 15:20:43< Soliton> normally those get doubled to escape them. 20180919 15:20:53< Soliton> but simple_wml does not do that. 20180919 15:21:26< Soliton> it probably hasn't come up until now because simple_wml is usually just used for reading. 20180919 15:21:50< Soliton> i think this should also corrupt server side replays though. 20180919 15:23:10< Soliton> perhaps the correctly formatted incoming WML is just saved there though, not sure. 20180919 15:23:44<+wesdiscordbot> For speed, simple_wml outputs attribute values with just memcpy(): https://github.com/wesnoth/wesnoth/blob/1.14/src/server/simple_wml.cpp#L761 20180919 15:24:12<+wesdiscordbot> If we want double quote escaping, we need to detect if there are any and disable the optimization in that case. 20180919 15:24:33< Soliton> unfortunately, yes. 20180919 15:27:42< Soliton> unless we escape them in the value already but then it needs to be undone on requesting a proper value. 20180919 15:28:19< Soliton> i think that might actually be how it's supposed to work. 20180919 15:28:27<+wesdiscordbot> I'd guess that accessing values is more common than writing WML, so it's better to keep strings unescaped in the values. 20180919 15:28:46< Soliton> the escaping is not removed on deserialising afaict. 20180919 15:29:39< Soliton> line 307 it just skips over doubled double quotes. 20180919 15:30:09< Soliton> every user of simple_wml needs to be aware of this then of course... 20180919 15:31:15< Soliton> the problem currently is that the addon server has an error message with a double quote in it and it cannot send it out because simple_wml complains. 20180919 15:33:21-!- gfgtdf [~Daniel@x4dbc6595.dyn.telefonica.de] has joined #wesnoth-dev 20180919 15:33:38<+wesdiscordbot> I'd say that when parsing WML and running into an escaped quote, simple_wml should disable its "obtain a string_span to the source string" optimization and just duplicate the string. 20180919 15:34:20<+wesdiscordbot> It would be too much of a gotcha to pass duplicated quotes to code that attempts to read the attributes, and too big a performance penalty to be duplicating strings on accessing them. 20180919 15:35:15< Soliton> yeah, i agree on the gotcha. 20180919 15:35:55< gfgtdf> i think you just haev to esacpe the quite before putting it into the simple_wml data. 20180919 15:36:01< gfgtdf> either in set_attr or in the caller 20180919 15:36:21< Soliton> then you have to unescape it on read. 20180919 15:36:41<+wesdiscordbot> Simple_wml parsing ccode does not have the liberty to edit the source buffer. 20180919 15:36:45< Soliton> currently the code suggests that that is expected though. 20180919 15:36:45<+wesdiscordbot> *code 20180919 15:37:19< Soliton> (i mean it expects already escaped quotes not that it unescapes on read.) 20180919 15:38:24< gfgtdf> m actuall suprised the addon server used simple_wml, i thought it woiudl us the normal config class. 20180919 15:39:03< Soliton> it was converted to the same network handling as wesnothd some time. 20180919 15:39:13< gfgtdf> hm ok. 20180919 15:41:29< Soliton> if what jyrkive suggest is not too much of a performance issue i'd prefer to change simple_wml to that. 20180919 15:41:46< Soliton> less surprising for the user. 20180919 15:41:49< gfgtdf> for the unexacling i think it's better to just do this one the caller side on the few cases where the read attribute is 'pared' can can actually contain, doublequotes. which shoudl be ratre, in fact i dont think there exists even one. 20180919 15:42:06<+wesdiscordbot> It would only be active for strings which actually contain double quotes. 20180919 15:42:19< Soliton> yes, that's important. 20180919 15:42:29< Soliton> and might be enough to not make it a performance issue. 20180919 15:43:02< gfgtdf> what exactly was hze suggesting ? 20180919 15:43:17<+wesdiscordbot> I think the biggest performance hit would be from checking if there are any (especially if the string is very long), and the branch for the two possibilities. 20180919 15:43:35-!- irker100 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20180919 15:43:47< gfgtdf> checking for quotes in set_attr is more? 20180919 15:44:21<+wesdiscordbot> Not in set_attr(), but in output() and the constructor. 20180919 15:44:39< Soliton> why not just the constructor? 20180919 15:44:47< gfgtdf> so you want that simple_wml contain unescaped nodes? 20180919 15:44:54< gfgtdf> to contain* 20180919 15:44:55< Soliton> there it parses the incoming WML either way. 20180919 15:45:21<+wesdiscordbot> It would also need to produce valid WML. 20180919 15:46:57< Soliton> if someone modifies the WML? i suppose so. i'd think checking in set_attr() might be better for that though. 20180919 15:47:36< Soliton> assuming it's not really used with big strings. 20180919 15:48:25<+wesdiscordbot> The main problem with storing escaped attributes would be with attr(). It would need to unescape attributes before returning them. 20180919 15:48:46<+wesdiscordbot> I suspect it would be a bigger performance hit than unescaping in the parsing code. 20180919 15:48:50< Soliton> it doesn't do that currently either though. 20180919 15:48:52< gfgtdf> pleas emake a pr before you change something. 20180919 15:48:58<+wesdiscordbot> Sure. 20180919 15:49:25< Soliton> i think we should just fix that one error message for now since that's the simplest. 20180919 15:49:40< Soliton> and likely there really is no other actual issue currently. 20180919 15:50:32< Soliton> but it means simple_wml is surprising to use. 20180919 15:51:05< Soliton> this issue should at least be documented then. 20180919 15:53:29<+wesdiscordbot> Is this the problematic error message? 20180919 15:53:30<+wesdiscordbot> https://github.com/wesnoth/wesnoth/commit/01aa127dfb6340721552659e79e649b3a8ebe1c8 20180919 15:53:53<+wesdiscordbot> It's the only one with embedded quotes I found in a quick search. 20180919 15:54:15< Soliton> it's line 808 in src/campaign_server/campaign_server.cpp 20180919 15:54:32< Soliton> the message about invalid file names. 20180919 15:55:03<+wesdiscordbot> Ah, I see. I'll use that one for testing. 20180919 15:55:53< Soliton> might be nice to add unit tests for simple_wml... :-P 20180919 15:57:08<+wesdiscordbot> I think unit tests aren't allowed to depend on wesnothd at the moment. (That's where simple_wml lives.) 20180919 15:57:29< Soliton> oh, i see. 20180919 16:01:24< Soliton> best would be to fix send_error() to do the escaping. 20180919 16:01:51< Soliton> there is the same issue for that extra_data argument. 20180919 16:06:45< Soliton> if you fix it you can close issue #3567. 20180919 16:10:00-!- irker618 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20180919 16:10:00< irker618> wesnoth: V N wesnoth:master 6010ffe98ee2 / data/lua/on_event.lua: prevent double execution of on_event.lua https://github.com/wesnoth/wesnoth/commit/6010ffe98ee2dd4450ec8fa42e89d6e0557c8dad 20180919 16:45:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180919 17:44:58<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/492028333803044865/unknown.png 20180919 17:45:16<+wesdiscordbot> Sigh. Campaignd skipped variable initialization with a goto. 20180919 17:45:25<+wesdiscordbot> One of the lesser known pitfalls of C++. 20180919 17:45:37<+wesdiscordbot> Oh well. Better to run into this here than in production... 20180919 18:05:37< irker618> wesnoth: Jyrki Vesterinen wesnoth:simple_wml_double_quotes 2d6ebe7e809e / src/server/ (simple_wml.cpp simple_wml.hpp): Simple_wml: support embedded quotes in strings https://github.com/wesnoth/wesnoth/commit/2d6ebe7e809ed28ae5a863f20bfcbfe916dc0de0 20180919 18:07:46<+wesdiscordbot> Soliton, gfgtdf, pull request is up: https://github.com/wesnoth/wesnoth/pull/3569 20180919 18:46:43-!- TC01 [~quassel@venus.arosser.com] has quit [Ping timeout: 246 seconds] 20180919 18:47:07-!- TC01 [~quassel@venus.arosser.com] has joined #wesnoth-dev 20180919 18:52:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180919 18:52:13-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180919 19:28:26< irker618> wesnoth/wesnoth:1.14 josteph 91bca769d7 Commandline: --campaign-skip-story skips AppVeyor: vs2015/Release Failed 20180919 19:28:27< irker618> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-1.14-4852 20180919 19:49:47-!- travis-ci [~travis-ci@ec2-174-129-160-194.compute-1.amazonaws.com] has joined #wesnoth-dev 20180919 19:49:48< travis-ci> wesnoth/wesnoth#19438 (simple_wml_double_quotes - 2d6ebe7 : Jyrki Vesterinen): The build failed. 20180919 19:49:48< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/430670734 20180919 19:49:48-!- travis-ci [~travis-ci@ec2-174-129-160-194.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180919 20:01:11-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds] 20180919 20:39:29-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20180919 22:28:55-!- irker618 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20180919 22:29:09-!- irker220 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20180919 22:29:09< irker220> wesnoth/wesnoth:master V N 6010ffe98e prevent double execution of on_event.lua AppVeyor: All builds passed 20180919 22:52:55-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20180919 23:16:12-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180919 23:16:18-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180919 23:48:24-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev --- Log closed Thu Sep 20 00:00:40 2018