--- Log opened Mon Jul 10 00:00:32 2017
20170710 00:00:47< DeFender1031> vultraz_iOS, where I'd take the opposite approach of focusing more on preserving old behaviors for at least one stable release while deprecating them for eventual removal unless absolutely impossible to do so.
20170710 00:01:02< vultraz_iOS> I'm saying we have a chance here, with a_r coming, to throw out what doesn't work and really develop a *stronger system*
20170710 00:01:16< vultraz_iOS> We need to stop acting like just because something is so that then it's sacrosanct. 
20170710 00:01:40< DeFender1031> vultraz_iOS, to be fair, it was my first serious WML work. My second cutscene only took a few weeks. (I only have maximum one day a week to work on it really.)
20170710 00:02:05< vultraz_iOS> DeFender1031: you should be able to do it in one day
20170710 00:02:15< vultraz_iOS> And you would if we gave authors the tools.
20170710 00:02:22< DeFender1031> vultraz_iOS, And what I'm saying is that there's no reason that the existing system can't STILL work IN ADDITION to the new, preferred syntax, whatever that may be.
20170710 00:02:40< vultraz_iOS> sure. as long as the old system is deprecated.
20170710 00:02:48< vultraz_iOS> but certain people would object to even that
20170710 00:03:19< DeFender1031> Also, in terms of animated cutscenes, there's a lot of juggling between animations and ActionWML. That juggling wouldn't disappear just because we had a better syntax.
20170710 00:03:34< vultraz_iOS> That's why I'm saying we don't just need better syntax
20170710 00:03:43< vultraz_iOS> We need better design here
20170710 00:04:45< DeFender1031> Honestly, it would help a lot if there was a less hacky way to do animations DURING other ActionWML than creating temporary standing animations for random units.
20170710 00:05:02< DeFender1031> (I do that in at least a couple of places.)
20170710 00:05:06< vultraz_iOS> again, *better design needed*
20170710 00:05:13< DeFender1031> Yes, I'm agreeing with you here.
20170710 00:05:26< DeFender1031> The question is what does a better design even look like?
20170710 00:05:34< vultraz_iOS> I'm not sure yet
20170710 00:05:58< vultraz_iOS> Anura and FFL provide good examples that we should take from but obv unless we decide we want to convert to Anura our system will look different
20170710 00:07:04< vultraz_iOS> But we're not even trying to come up with a better design
20170710 00:07:09< vultraz_iOS> That's the problem
20170710 00:07:26< DeFender1031> one piece of better design that would help, but not cover all the cases one might want in this regard would be the thing I suggested a while ago about allowing a subtag of [message] that takes a series of actions which will be executed even if the message is still on the screen.
20170710 00:07:29< vultraz_iOS> We need to actually commit to changing things.
20170710 00:08:02< DeFender1031> another might be to provide some way to create animations independant of units.
20170710 00:08:10< DeFender1031> some kind of global animation tag.
20170710 00:08:13-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 00:08:24< vultraz_iOS> all that could be done!
20170710 00:08:28< celticminstrel> I'm not so convinced that Anura/FFL is a good example to take from though.
20170710 00:08:35< vultraz_iOS> especially with a_r, everything is more performance friendly!
20170710 00:08:44< DeFender1031> in addition, it'd be great if whatever that is could allow specific event wml to be triggered at specific points in the animation.
20170710 00:09:27< celticminstrel> There are already animations independent of units. They're called terrain animations. :P
20170710 00:09:39< celticminstrel> (And can also be done with [item] IIRC.)
20170710 00:09:40< DeFender1031> vultraz_iOS, I know it could be done. You seem to think I'm disagreeing with you on something here. I'm trying to contribute to your argument by making practical suggestions of what working toward a better design might look like.
20170710 00:10:05< vultraz_iOS> No, I know you agree with me.
20170710 00:10:12< DeFender1031> vultraz_iOS, the only point where we may slightly disagree is the status of trying to do things in a way in which the old syntaxes are still valid, at least for the moment.
20170710 00:10:35< vultraz_iOS> Yes, we'd need to do that.
20170710 00:10:43< vultraz_iOS> But especially zookeeper will oppose that.
20170710 00:10:54< vultraz_iOS> that being deprecation of anything.
20170710 00:11:12< celticminstrel> I'm pretty sure you can do it in a way that zookeeper would approve.
20170710 00:11:46< celticminstrel> I think the key to zookeeper's objections is that players see the deprecation messages; if they were only shown to developers, I don't think he'd have a problem.
20170710 00:12:09< vultraz_iOS> No, his problem is people having to change anything at all
20170710 00:12:12< DeFender1031> but anyway, message tags with action children, global animations that can be triggered on a hex rather than on a particular unit, also with the ability to include action wml at a certain point in the animation, possibly expanding [item] to give it a full animation syntax (for repeating hex-based animations), I have a lot of ideas for how more versatility in terms of graphics and timing could be improved.
20170710 00:12:27< celticminstrel> I'm also going to point out that, for the most part, we do not have the option to scrap one system and replace it with another.
20170710 00:12:51< vultraz_iOS> We have complete control of the codebase.
20170710 00:12:56< vultraz_iOS> We can do whatever we want.
20170710 00:13:04< DeFender1031> vultraz_iOS, I believe celticminstrel is correct. I've seen zookeeper say that multiple times.
20170710 00:13:16< vultraz_iOS> I'm not saying we should, but we have the option.
20170710 00:13:55< celticminstrel> Note that I'm assuming the premise that all old code from the 1.12 release should continue to work as it did before.
20170710 00:14:19< vultraz_iOS> For a stable series, yes.
20170710 00:14:21< celticminstrel> I know you've said that this isn't currently the case, but if there are cases where 1.13 has broken old 1.12 code, those are bugs that need to be fixed, preferably before the 1.14 release.
20170710 00:14:32< DeFender1031> Which raises another point. We have a debug mode. It's trivial to create a message that shows prominently in debug mode and not at all elsewise.
20170710 00:14:50< celticminstrel> Yeah, I think I've done that in some cases already.
20170710 00:15:24< DeFender1031> well, here's the thing, there's some stuff that CAN'T work the smae as it did in 1.12. FOr example, I have a bunch of custom graphics that just don't fit.
20170710 00:15:30< vultraz_iOS> I have no problem with showing deprecation notices in debug mode only.
20170710 00:15:46< vultraz_iOS> and yes, what DeFender1031 says is true
20170710 00:16:09< vultraz_iOS> there has never, as far as I know, been a clean stable-to-stable transition for creators
20170710 00:16:25< DeFender1031> but yes, we need to A: be willing to deprecate things we don't like, but B: leave them around and IN PERFECT WORKING ORDER for at least one major stable release
20170710 00:16:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170710 00:17:18< vultraz_iOS> Can't disagree with that.
20170710 00:18:04< DeFender1031> vultraz_iOS, even graphics could theoretically be done, if for example the entire 1.12 graphics library were included and whether it used the 1.12 definitions or the 1.14 definitions was based on some define in the WML. (Note, I'm not saying this is a good idea necessarily, it's just an example of an extreme case where it seems like there's no way to keep back-compat, but with some creative and potentially temporarily 
20170710 00:18:05< DeFender1031> bloated code, it actually is possible)
20170710 00:18:29< vultraz_iOS> technically
20170710 00:18:34< vultraz_iOS> though a massive PITA
20170710 00:19:03< DeFender1031> Of course. Like I said, I'm not suggesting it be done, I think graphics is a fair are to expect people to need to do some updating.
20170710 00:19:17< DeFender1031> area*
20170710 00:19:54< DeFender1031> My point was simply, backwards compatibility is doable in far more cases than one might initially think, and certainly in far more cases than are being done.
20170710 00:20:10< vultraz_iOS> I think the first thing we should work on (besides perhaps some low-hanging fruit you mentioned, but I think we might need to consider the design for those) is getting rid of [if] and [else] in animations
20170710 00:20:15< DeFender1031> But at the same time "never ever deprecate or remove anything ever" is idiotic as well.
20170710 00:20:45< DeFender1031> vultraz_iOS, honestly, it's not that they exist that's the problem, it's the names.
20170710 00:21:15< DeFender1031> vultraz_iOS, if it were instead a "[split_definition]" tag, it would be far more intuitive.
20170710 00:21:46< celticminstrel> The best way to keep backwards compatibility with image paths is probably to use symlinks or similar.
20170710 00:21:48< DeFender1031> I mean, it's still a pretty crappy design, but it wouldn't be as frustrating
20170710 00:21:59< vultraz_iOS> Well, as I said I'd like it if we could use AnimationWML - which currently has the most control over drawing things - as a staging ground for better drawing syntax/design
20170710 00:22:02< celticminstrel> (And other resource paths, of course.)
20170710 00:22:39< DeFender1031> celticminstrel, symlinks aren't universally supported and can be messy. I'd opt for just a map in storage somewhere.
20170710 00:22:57< celticminstrel> I don't remember when Windows started supporting symlinks though, so you'd need to basically implement your own symlink-equivalent somehow.
20170710 00:23:24< celticminstrel> A map in storage is a very viable method, actually.
20170710 00:23:25-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 00:23:33< DeFender1031> celticminstrel, but that only solves the problem of moved images. It doesn't solve, for example, the fact that my custom "water with cliffs" or "wall with door" terrains look terrible because the water and walls no longer match.
20170710 00:23:39< celticminstrel> I think we already have such a map in the wmllint source code, in fact.
20170710 00:23:59< celticminstrel> DeFender1031: Yeah, okay, that one's harder.
20170710 00:24:13< celticminstrel> That would require using a new name whenever you drastically changed the image.
20170710 00:24:19< DeFender1031> celticminstrel, but again, I think that graphics (the actual images, not the paths) IS an area where it's reasonable to expect creators to need to update.
20170710 00:24:57< DeFender1031> if it were just the graphics no longer matching the new style that was causing me issues on 1.13, i'd have had my campaign ported months ago.
20170710 00:27:21< DeFender1031> but I have issues where stuff i've done actually renders differently or on different layers, missing paths, invalid WML edge cases that used to be valid, Lua errors... not to mention the performance issues and flickers of unwanted frames which should become moot with a_r.
20170710 00:29:56< DeFender1031> I think there are two problems here. The first is the need for a new design. The second is the need to have an environment in which new designs can be created without being held back indefinitely. I'm going to suggest something radical: I think that someone needs to create an official deprecation policy.
20170710 00:30:23< celticminstrel> WML edge cases are likely things that aren't entirely understood and thus may be unmaintained. If you need a WML edge case to work, I suggest trying to write a test case.
20170710 00:30:51< DeFender1031> celticminstrel, I know, I'm sure that's the case, but that's not entirely my point.
20170710 00:31:26< DeFender1031> anyway, if there were an official deprecation policy, it might do away with all the arguments over whether/when it's safe to remove something.
20170710 00:33:07< DeFender1031> As well as balance out the clash between those who are too ready to remove things and those who are too hesitant to do so.
20170710 00:34:29< DeFender1031> ARE there official policies on development practice anywhere?
20170710 00:35:24< DeFender1031> Not coding conventions, obviously there are policies on that, but are there any policies on logistical practice?
20170710 00:35:41< DeFender1031> And if not, what would the best section of the forum be to start such a conversation?
20170710 00:35:51< vultraz_iOS> what type of development practice?
20170710 00:37:39< DeFender1031> Aside from deprecation policy which is what I'm trying to suggest here, I'd think that such a policy would be in a similar category with git structure best-practice, how to determine when to commit to master vs. make a PR, etc.
20170710 00:37:50< vultraz_iOS> https://wiki.wesnoth.org/CodingStandards
20170710 00:37:53< vultraz_iOS> https://wiki.wesnoth.org/DeveloperGuide
20170710 00:37:58< DeFender1031> When someone is made a developer?
20170710 00:38:02< DeFender1031> etc.
20170710 00:38:15< vultraz_iOS> though the latter is basically useless
20170710 00:38:21< DeFender1031> or not made a developer, but given access... whatever, you get the kinds of things I mean.
20170710 00:38:44< DeFender1031> vultraz_iOS, yeah, those are what I meant by coding convention.
20170710 00:38:53< DeFender1031> I'm talking logistical policies.
20170710 00:39:04< vultraz_iOS> https://wiki.wesnoth.org/DevelopersHome
20170710 00:39:15< vultraz_iOS> isn't really anything
20170710 00:39:23< vultraz_iOS> written down, at least
20170710 00:39:30< DeFender1031> yeah, those other two pages aren't really policies per-se.
20170710 00:39:39< DeFender1031> But that's what I mean.
20170710 00:39:47< vultraz_iOS> https://wiki.wesnoth.org/Git_for_Wesnoth_Crash_Course is useful
20170710 00:39:55< DeFender1031> I think it might be time to create a set of official logistical policies.
20170710 00:40:23< vultraz_iOS> it basically describes the h git structure best-practice, how to determine when to commit to master vs. make a PR" part
20170710 00:40:47< DeFender1031> When and how can things be deprecated, formalize the "odds are dev, evens are release" convention, describe what the rules are for LONG-TERM development.
20170710 00:41:19< DeFender1031> am I making any sense?
20170710 00:41:20< vultraz_iOS> yeah, we should write something like that..
20170710 00:41:43< DeFender1031> I need to head off to bed soon, but I can probably make a stab at something tomorrow
20170710 00:44:29< DeFender1031> I'd like to propose it on the forum first, though I think it'd probably make sense on the developer's forum, which I don't have access to post in, but which I think (hope) I've contributed enough at least in the form of consultation (or perhaps incoherent rambling) that I might request it.
20170710 00:46:22< DeFender1031> Besides, as I understand, there isn't really an official policy yet on how "involved" someone needs to be before they're considered a dev, right? :P
20170710 00:46:42< DeFender1031> (That'd be another good thing to have a solid policy on.)
20170710 01:17:16< vultraz_iOS> DeFender1031: the "policy" has always loosely been 2 accepted patches/PRs of "significant" impact
20170710 01:25:43-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 01:41:28-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 01:45:02< celticminstrel> Finally fixed the blending issue in my test code. >_>
20170710 01:52:11< vultraz_iOS> celticminstrel: how is the shader conversion going
20170710 01:52:50< celticminstrel> To be quite frank, the total progress this weekend probably amounts to nearly zero. What I did this weekend was rearchitecting the system.
20170710 01:53:05< celticminstrel> Which actually makes it closer to the existing system.
20170710 01:53:21< celticminstrel> That wasn't the intent though. The intent was to make the next step easier.
20170710 01:53:24< vultraz_iOS> That sounds like it could be a good thing or a bad ting...
20170710 01:54:23< vultraz_iOS> Is it similar to the users or internally
20170710 01:54:35-!- Bonobo [~Bonobo@203.63.51.218] has joined #wesnoth-dev
20170710 01:54:41< celticminstrel> Well, that's a silly question.
20170710 01:54:55< celticminstrel> No matter what I do it'll definitely end up being identical to the users.
20170710 01:55:01< celticminstrel> It's closer internally.
20170710 01:55:13< celticminstrel> The previous version was somewhat hacked-together.
20170710 01:55:23< vultraz_iOS> alright
20170710 01:55:33< vultraz_iOS> the structure of the internals don't matter as long as they're good
20170710 01:55:39< celticminstrel> (I say identical, but... there might actually be a few minor things that work in the new version that didn't work before.)
20170710 01:55:52< celticminstrel> (But I'm sure no-one will complain about this.)
20170710 01:57:30< celticminstrel> ATM I'm actually making everything public, but that would change in the final version included in Wesnoth.
20170710 02:02:32< celticminstrel> The result of this work will be that every image path will be represented by an object, and you can simply call the draw() method on it.
20170710 02:02:41< celticminstrel> The method takes x and y coordinates.
20170710 02:03:06< celticminstrel> The object knows its own size, so you don't need a rect - just the top left corner.
20170710 02:04:22< celticminstrel> I'm using typedefs of std::array to stand in for GLSL vector types.
20170710 02:04:49< celticminstrel> GLSL arrays are represented by std::vector, which isn't exactly ideal, but I can't exactly use std::array for both.
20170710 02:05:18< celticminstrel> Oh, std::array for matrix types too.
20170710 02:06:47< celticminstrel> I haven't even looked into caching shaders that are identical except for the parameters.
20170710 02:07:28< celticminstrel> Which means those that use the exact same IPFs in the same order but with different arguments.
20170710 02:07:55< celticminstrel> (Roughly; there are some exceptions to that rule, as I've mentioned before.)
20170710 02:20:55< celticminstrel> I think it would be better to drop the priority nature of TC, RC, and PAL, but I wonder how much that would break.
20170710 02:21:12< celticminstrel> It makes sense that, in the majority of cases, you want them to be applied first.
20170710 02:21:41< celticminstrel> But I'm sure there could be situations where you might not want them to be applied forst.
20170710 02:21:43< celticminstrel> ^first
20170710 02:21:54< celticminstrel> Example! I just thought of a really good one, even.
20170710 02:23:06< celticminstrel> my_unit.png~CS(12,120,-50)~BLIT(my_unit_tc.png)~RC(magenta>red)
20170710 02:23:47< celticminstrel> (I think blit also requires coordinates, but in this case they'd be 0,0 which IMO should be the default if they're omitted anyway; not sure if it is.)
20170710 02:24:11< celticminstrel> ...come to think of it, blit is partly a translation and partly a blend...
20170710 02:24:31< celticminstrel> ...might it be a bit easier than I thought to implement it...?
20170710 02:24:52< celticminstrel> Of course it does still have the complication of taking an IPF as input, though.
20170710 02:54:01-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 03:21:54-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 03:41:23-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170710 03:41:29-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170710 03:48:48-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 04:04:50-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 04:18:04-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 04:29:28< vultraz_iOS> yes, the default coords are 0,0
20170710 04:33:30< celticminstrel> I've got the new version at parity with the old now.
20170710 04:33:44< celticminstrel> By which I mean all the IPFs that worked before work now.
20170710 04:33:52< vultraz_iOS> :o
20170710 04:33:55< celticminstrel> Sooo the next step is, once again, figuring out ~L().
20170710 04:34:03< vultraz_iOS> what's wrong with L?
20170710 04:34:09< vultraz_iOS> (do we need it?)
20170710 04:34:15< celticminstrel> The same thing that's wrong with ~BLIT() and ~MASK()
20170710 04:34:31< celticminstrel> One of its arguments is a nested IPF chain.
20170710 04:34:51< celticminstrel> (Actually I'm not quite sure if ~:() does support nested IPFs, but there's no particular reason not to, right?)
20170710 04:34:57< celticminstrel> ^~L()
20170710 04:35:12< celticminstrel> (Certainly ~BLIT() does at the very least, so I need to be able to handle that.)
20170710 04:35:28< celticminstrel> ~L() is a little easier to work with than ~BLIT() though.
20170710 04:35:49< vultraz_iOS> again, do we need it.
20170710 04:35:50-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 04:35:53< celticminstrel> Probably.
20170710 04:36:07< celticminstrel> But that's not really a question we should be asking anyway.
20170710 04:36:16< vultraz_iOS> It sounds like it was an IPF designed to do something that could be done better now.
20170710 04:36:27< celticminstrel> I kinda doubt it could be done better now?
20170710 04:37:30< celticminstrel> Anyway, it doesn't matter, because implementing ~L() is trivial once I have the ability to parse nested IPF chains, and we absolutely need that capability for ~BLIT() at the very least.
20170710 04:38:30< celticminstrel> I mean, I could implement ~BLIT() first and then ~L(), I suppose. But, I think ~BLIT() may have a few other considerations that might make it a bit harder to focus on the nested IPF chains.
20170710 04:38:51< celticminstrel> ~L() on the other hand is pretty much just a form of blending.
20170710 04:39:29< celticminstrel> Basically, I don't need to worry about texture coordinates in ~L(). I do have to worry about texture coordinates in ~BLIT().
20170710 04:40:28< celticminstrel> I've already written the GLSL blending function for ~L().
20170710 04:40:40-!- irker305 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170710 04:40:40< irker305> wesnoth: Richard Kettering wesnoth:master 5a5ea98b805f / data/core/images/units/dwarves/ (10 files): Animation frames for a se run of the dwarven stalwart. https://github.com/wesnoth/wesnoth/commit/5a5ea98b805f0da09fe9f030bee64c46f18a4e46
20170710 04:40:43< celticminstrel> It's four lines plus the closing brace.
20170710 04:40:53< vultraz_iOS> heh
20170710 04:40:55< vultraz_iOS> ok
20170710 04:42:11< vultraz_iOS> I'm still rather miffed that we can't implement blit and crop as "render here at this place" or "take this source rect".
20170710 04:42:17< celticminstrel> I think there could be problems with SCALE vs SCALE_SHARP. ATM I've only implemented SCALE (though I don't remember if it's using linear or nearest).
20170710 04:42:44< celticminstrel> For blit and crop I don't think that's really an issue.
20170710 04:42:53< celticminstrel> Crop is a simple scaling of texture coordinates.
20170710 04:43:03< celticminstrel> Blit is a simple translation of texture coordinates, I think.
20170710 04:43:30< vultraz_iOS> Is it still a case in OGL that texture scaling methods are applied when its created?
20170710 04:43:42< celticminstrel> ???
20170710 04:44:21< vultraz_iOS> Right now, I have to keep two different texture caches, one for nn textures, one for linear textures
20170710 04:44:40< celticminstrel> Uh, why would you need that?
20170710 04:45:08< vultraz_iOS> that's because textures are created with a scale type, which is the value of the SDL_HINT_RENDER_SCALE_QUALITY hint 
20170710 04:45:10< celticminstrel> You can easily switch a texture between the two, so unless you need to use the same texture with both scaling methods at the same time, there should be no need for separate caches.
20170710 04:45:15< irker305> wesnoth: Richard Kettering wesnoth:master 003508d5ef20 / data/core/images/units/dwarves/ (8 files): Animation frames for a ne attack of the dwarven guard. https://github.com/wesnoth/wesnoth/commit/003508d5ef20187e192a07232ccad4bca6f74d56
20170710 04:45:19< vultraz_iOS> you can't change a texture's scale type after that
20170710 04:45:29< celticminstrel> I have no idea what SDL_HINT_RENDER_SCALE_QUALITY is.
20170710 04:45:40< vultraz_iOS> it's a hint specifying scale quality in SDL2
20170710 04:45:41< celticminstrel> But you can easily change a texture's scaling algorithm with OpenGL calls.
20170710 04:46:08< vultraz_iOS> linear, nn, or anisotropic
20170710 04:46:10< celticminstrel> My texture class has functions to switch between them.
20170710 04:46:20< celticminstrel> Either linear or nearest.
20170710 04:46:31< vultraz_iOS> if that hint is set to nn when its created, you can't switch it to linear and get the texture scaled linear
20170710 04:46:31< celticminstrel> (I think nearest is the same as nearest neighbour.)
20170710 04:46:53< celticminstrel> You can't even set the scaling algorithm when a texture is created in OpenGL.
20170710 04:47:08< vultraz_iOS> no.. you misunderstand...
20170710 04:47:12< vultraz_iOS> it's a hint
20170710 04:47:17< vultraz_iOS> you set it BEFORE creating the texture
20170710 04:47:23< celticminstrel> Yeah, I have no clue what this is.
20170710 04:47:29< vultraz_iOS> gdi
20170710 04:47:40< vultraz_iOS> it's a flag specifying what the current scaling method is
20170710 04:47:47< vultraz_iOS> any new textures are created with that scaling method
20170710 04:47:47< celticminstrel> In particular, I have no idea what it means in OpenGL terms.
20170710 04:48:06< vultraz_iOS> all I'm asking
20170710 04:48:16< celticminstrel> And you'll need to use OpenGL in any case, so it's probably not worth even worrying about something that's specific to SDL.
20170710 04:49:04< vultraz_iOS> is if, in OGL, you can have a texture rendered with different scaling method even after its creation?
20170710 04:49:26< celticminstrel> AFAIK, yes.
20170710 04:49:42< celticminstrel> It should use whatever scaling mode is currently set via glSetParameter.
20170710 04:49:49< celticminstrel> ^glSetTexParam
20170710 04:49:59< celticminstrel> ...
20170710 04:50:04< celticminstrel> glTexParameter
20170710 04:50:11< vultraz_iOS> alright
20170710 04:50:39< celticminstrel> The only problem I'm worried about is, what if someone uses ~SCALE() and ~SCALE_SHARP() in the same IPF chain?
20170710 04:51:21< vultraz_iOS> IDFK
20170710 04:51:24< celticminstrel> (Uses within a BLIT() etc don't count as in the same chain.)
20170710 04:51:40< vultraz_iOS> use the first ignore the second
20170710 04:52:15< celticminstrel> Probably the only way to make that work exactly as you'd expect would be to manually implement the scaling algorithms in shader code.
20170710 04:52:28< vultraz_iOS> GDI
20170710 04:52:32< celticminstrel> Otherwise, yeah, you'd have to pick one using some criteria.
20170710 04:52:39< celticminstrel> I have no idea what GDI means BTW.
20170710 04:52:40< vultraz_iOS> just use the first one!
20170710 04:52:49< vultraz_iOS> GDI = god dammit
20170710 04:53:35< celticminstrel> TBF, I doubt manually implementing the scaling algorithms in shader code is any more complicated than implementing blur in shader code, but it'd still be extra work, so I'm not going to prioritize it.
20170710 04:54:15< celticminstrel> (Which also means I'm going to ignore ~XBRZ() until the very end.)
20170710 04:54:28< vultraz_iOS> xBRZ is a whole fucking mess :(
20170710 04:54:43< celticminstrel> Not sure what gives you that idea. >_>
20170710 04:55:01< vultraz_iOS> it's surface based
20170710 04:55:08< vultraz_iOS> how do we turn it into a shader
20170710 04:55:26< celticminstrel> Probably rather similar to how you'd write a blur shader.
20170710 04:56:26< vultraz_iOS> another question
20170710 04:56:31< celticminstrel> BTW, I'm told that if statements can be slow in shaders, but I'm not holding back on using them at all.
20170710 04:57:23< vultraz_iOS> why not deprecate every scale IPF but ~SCALE() and add a final algorithm argument. ie, image.png~SCALE(sizex, sizey, NN)
20170710 04:57:27< celticminstrel> (In some cases it's possible to avoid if statements with careful math. I'm not bothering. That's something that should be done in a separate optimization stage if it is deemed necessary.)
20170710 04:58:12< celticminstrel> Well, I wouldn't be opposed to removing SCALE_SHARP and pushing the algorithm to a separate argument. IIRC SCALE_SHARP was added in 1.13 anyway, so we probably don't even need to deprecate.
20170710 04:58:42< celticminstrel> There's no reason to do anything to SCALE_INTO() - it's just a SCALE which modifies the input size to preserve aspect ratio.
20170710 04:58:48< celticminstrel> And XBRZ...
20170710 04:59:05< celticminstrel> I don't think you can push that to an extra argument to SCALE(), because it works totally differently.
20170710 04:59:10< vultraz_iOS> yeah
20170710 05:00:04< celticminstrel> My shader stuff does already handle SCALE and SCALE_INTO. They're the only image mods that don't inject any shader code. :P
20170710 05:00:13< celticminstrel> All they do is modify the target size.
20170710 05:00:45 * celticminstrel wants to add SHEAR(), mainly because I actually wrote a function for it already. >_>
20170710 05:00:56< vultraz_iOS> shear?
20170710 05:01:15< celticminstrel> It turns a square into a rhombus.
20170710 05:01:21< celticminstrel> Or a rectangle into a parallelogram.
20170710 05:01:32< celticminstrel> Is that explanation enough?
20170710 05:01:55< vultraz_iOS> i see
20170710 05:02:15< celticminstrel> That's if you shear in only one direction, mind you. I'm not sure what happens if you shear in both directions.
20170710 05:03:15< celticminstrel> Maybe I'll add it when I get back to ROTATE() with arbitrary angles.
20170710 05:04:11< celticminstrel> Anyway, I definitely need to sleep.
20170710 05:04:44< vultraz_iOS> i wish IPFs were accessible in a functional context instead of as part of data stings
20170710 05:04:56< celticminstrel> ?
20170710 05:05:26< vultraz_iOS> strings*
20170710 05:05:33< celticminstrel> ?
20170710 05:05:49< vultraz_iOS> nevermind
20170710 05:05:55< celticminstrel> ...
20170710 05:06:14< vultraz_iOS> just more wishfullness that we had a functional language and didn't do all this crap in WML.
20170710 05:07:44< vultraz_iOS> functional FTW
20170710 05:09:21< celticminstrel> ...
20170710 05:10:54< vultraz_iOS> what's wrong with functional
20170710 05:18:17-!- ancestral [~anonymous@63-231-159-160.mpls.qwest.net] has quit [Quit: ancestral]
20170710 05:20:34-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170710 05:23:05-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 05:25:40-!- ancestral [~anonymous@63.231.159.160] has joined #wesnoth-dev
20170710 05:39:25< celticminstrel> Nothing's wrong with functional. WFL is definitely functional.
20170710 05:41:22-!- RatArmy_ [~ratarmy@om126200126115.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 05:44:35-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170710 06:31:13-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170710 06:44:21-!- ancestral [~anonymous@63.231.159.160] has quit [Quit: ancestral]
20170710 07:06:44-!- RatArmy_ [~ratarmy@om126211114101.13.openmobile.ne.jp] has joined #wesnoth-dev
20170710 07:08:17-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170710 07:12:52-!- Bonobo [~Bonobo@203.63.51.218] has quit [Ping timeout: 260 seconds]
20170710 07:13:00-!- Bonobo [~Bonobo@203.63.51.218] has joined #wesnoth-dev
20170710 07:29:41-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20170710 08:15:24-!- RatArmy_ [~ratarmy@om126211114101.13.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 08:22:57< JyrkiVesterinen> celticminstrel: XBRZ is so expensive that it may be better to just run it on the CPU and cache the result.
20170710 08:27:05-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: Going somewhere]
20170710 08:57:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 09:14:16-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170710 09:33:20-!- RatArmy_ [~ratarmy@om126234114136.16.openmobile.ne.jp] has joined #wesnoth-dev
20170710 09:35:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170710 09:36:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 09:49:04-!- RatArmy_ [~ratarmy@om126234114136.16.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 09:56:13-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170710 09:57:06-!- RatArmy_ [~ratarmy@om126234114136.16.openmobile.ne.jp] has joined #wesnoth-dev
20170710 09:57:40-!- Kwandulin [~Miranda@p200300760F12B39B95D23881CF480F37.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170710 10:01:49-!- clavi [~clavi@v22017034422546657.goodsrv.de] has quit [Quit: ZNC - http://znc.in]
20170710 10:04:39-!- clavi [~clavi@v22017034422546657.goodsrv.de] has joined #wesnoth-dev
20170710 10:14:13-!- RatArmy_ [~ratarmy@om126234114136.16.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 10:16:06-!- RatArmy_ [~ratarmy@om126234114136.16.openmobile.ne.jp] has joined #wesnoth-dev
20170710 10:25:49-!- irker305 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170710 10:30:02-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170710 10:30:35-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 10:38:42-!- RatArmy_ [~ratarmy@om126234114136.16.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 10:50:31-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20170710 10:51:20-!- RatArmy_ [~ratarmy@om126234114136.16.openmobile.ne.jp] has joined #wesnoth-dev
20170710 10:53:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170710 10:54:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 11:01:37-!- Duthlet [~Duthlet@ipservice-092-211-172-179.092.211.pools.vodafone-ip.de] has joined #wesnoth-dev
20170710 11:03:02-!- Kwandulin [~Miranda@p200300760F12B39B95D23881CF480F37.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
20170710 11:31:21-!- Kwandulin [~Miranda@p200300760F12B39B85554C55010031CF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170710 11:44:34-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170710 11:50:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170710 11:50:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 11:54:34< DeFender1031> vultraz_iOS, good to know. Though my point is there's a difference between "we tend to loosely stick to xyz" and a formalized policy. A policy would also include what "significant impact" actually means.
20170710 12:06:09< DeFender1031> Yes, nested paths in BLIT, L, and MASK allow IPFs as well.
20170710 12:08:56< zookeeper> for what it's worth, my approach has never been "you must never break anything ever". what i'm primarily against is the frivolous breaking of common syntax/tags/macros because of stylistic reasons or because either someone thinks that a couple of lines of compatibility code is "code bloat" or because they just can't be bothered to write it.
20170710 12:09:41< zookeeper> suggestions for breaking this or that for no real reason besides "but it's better design :|" get thrown around all the time.
20170710 12:11:41< DeFender1031> TC, RC, and PAL don't really make sense to do later, as they swap very specific pixels that could be messed up by any other IPF. Even in celmin's BLIT example, there could be partially transparent pixels from the BLIT that screw up the RC. Still better to do it on each of the components separately. On the other hand, I think giving them higher priority is second-guessing a creator, who, if they want it before everything else,
20170710 12:11:42< DeFender1031>  should be putting it before everything else. If it weren't for the fact that there's already an established behavior, I'd say do them in order, but as it is, I wonder how many less-than-meticulous creators have used it out of order and would be affected by such a change.
20170710 12:16:17< zookeeper> i don't think the concern is so much to prevent people shooting themselves in the foot by putting the TC/RC/PAL call last in their particular hand-written IPF chain when logically it should be first, but rather to make sure things don't break when the game has to combine IPFs from multiple sources.
20170710 12:18:11< zookeeper> for example, if you have a unit with an [effect]-applied image_mod that forces its TC to be teal. that needs to occur before any other IPFs from other sources that might be affecting the unit.
20170710 12:20:22< DeFender1031> IIRC, shear in both directions will end up being a rotate if the given angle is the same (though it won't be a rotate by that angle, because the difference between a shear and a rotate is similar to the difference between linear and cartesian) and if they're not the same, it'll end up partly sheared and partly rotated.
20170710 12:22:31< vultraz_iOS> zookeeper: better design IS a real reason
20170710 12:23:04< zookeeper> vultraz_iOS, why are you working on wesnoth then when anura has better design?
20170710 12:23:04< DeFender1031> zookeeper, what you said about compatibility and such is exactly why I'm saying that an official policy should be written. The policy should include a rule to the effect of "new and better designs are fine and even encouraged, but compatility code should be added to support the existing design for at least one major release version".
20170710 12:23:43< vultraz_iOS> zookeeper: I was working briefly with Anura. The Wesnoth 2 project died in the water :|
20170710 12:23:51< vultraz_iOS> but mainly I just like coding.
20170710 12:24:12< vultraz_iOS> Anura has a higher barrier of entry because its engine code is a lot more complex and I don't know the codebase.
20170710 12:24:13< DeFender1031> zookeeper, ah, that's a good point about TC, RC, and PAL with multiple sources, though much of the ways in which that manifests (such as unit image mods) are not the best design either...
20170710 12:24:45< vultraz_iOS> But I did enjoy the ease of Anura when I was working with Argentum Age and Wesnoth 2
20170710 12:24:54< DeFender1031> vultraz_iOS, better design is not a real reason to not offer compatibility with the older, worse design where possible.
20170710 12:25:12< vultraz_iOS> sadly, CERTAIN PEOPLE (not you, zookeeper) decided the entire idea of Wesnoth 2 was shit
20170710 12:25:24< vultraz_iOS> *coughdugicough*
20170710 12:25:50< vultraz_iOS> and general toxic attitudes caused dave to basically say fuck it and abandon the project.
20170710 12:26:51< vultraz_iOS> I've invested 5 years into Wesnoth and I want to make it a good game.
20170710 12:27:14< vultraz_iOS> And it's how I've actually learned to program.
20170710 12:28:49< DeFender1031> It is a good game, it's just got some really crappy software design at the moment.
20170710 12:30:07< vultraz_iOS> for some reason this community has always been very resistant to change
20170710 12:30:45< zookeeper> resistant to change that breaks all their existing nice things, sure
20170710 12:31:37< vultraz_iOS> If we break it to give them nicer things it's worth it.
20170710 12:31:56< DeFender1031> I feel like I've been talking into a void.
20170710 12:32:22< DeFender1031> vultraz_iOS, more often than not, there are ways to give nicer things without breaking the existing nice things. More emphasis needs to be put on that.
20170710 12:32:26< vultraz_iOS> Let's at least not pretend everything we have - esp with WML - is gold. Like DeFender1031 said we have some shitty software designs at the moment.
20170710 12:32:37< vultraz_iOS> I agree compatibility should be maintained for awhile.
20170710 12:32:42< zookeeper> no one's pretending that
20170710 12:33:55< vultraz_iOS> But I don't really feel like all of us are committed to making things markedly better.
20170710 12:35:50< vultraz_iOS> You would be perfectly content if nothing ever changed again and the game froze in a stable release.
20170710 12:37:59< zookeeper> no
20170710 12:38:20< vultraz_iOS> That's the impression I've always gotten.
20170710 12:38:43< zookeeper> that's the impression you always want to reach no matter what i say :p
20170710 12:41:12< DeFender1031> And this is exactly why I think an official policy that everyone can agree on should be put into place, so that there won't be any such misunderstandings.
20170710 12:42:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170710 12:43:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 12:43:54< zookeeper> DeFender1031, well, any ideas for how one could formulate the idea of "don't break things unless there's a good reason to" in a way that "better design is good reason" isn't a universal excuse?
20170710 12:44:35< vultraz_iOS> I think the policy should be if something is broken compatibility should try to be maintained.
20170710 12:45:59< DeFender1031> zookeeper, I would focus less on reason and more on how long old designs still need to be maintained as deprecated before dropping them completely...
20170710 12:46:44< DeFender1031> zookeeper, better design IS a good reason. Often, maintaining outdated designs for too long prevents new features from being added, since the old designs would be incompatible.
20170710 12:47:00< DeFender1031> or rather CAN BE a good reason.
20170710 12:47:20< zookeeper> yes, the difference between "is" and "can be" is relevant in this case
20170710 12:47:27< DeFender1031> also fair.
20170710 12:48:49< DeFender1031> though, even if there's nothing solid AT THE MOMENT that any hypothetical old design is preventing, it's STILL a good idea to deprecate it for eventual removal (again, with a generous deprecation period) as things tend to come up, and you'll eventually wish that whatever the design is didn't have to continue to be supported.
20170710 12:52:47< zookeeper> i'm fine with a policy where compatibility is maintained only for one full stable cycle (so, 1.14 content would work in 1.16 with deprecation warnings where necessary, but not anymore in 1.17/1.18) for things that really are necessary to get rid of eventually for technical reasons. what i'm not fine with is doing that without reasonable effort to keep compatibility or without a decent 
20170710 12:52:47< zookeeper> _concrete_ reason for the change in the first place.
20170710 12:55:17< DeFender1031> So I think that's the main point of contention.
20170710 12:55:31-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170710 12:55:41< DeFender1031> I have to run out for a couple of hours, but I'd like to continue this when I get back.
20170710 12:56:47< celticminstrel> ...sounds like a missed a whole lot. :P Not really here even now though.
20170710 12:58:33< DeFender1031> But basically, the core of the issue is that I, vult, possibly celmin? think anything should be deprecation-worthy so long as there's some viable replacement which has feature parity. You, gfgtdf, and maybe some others are more of the opinion that even things for which there is feature parity should not be removed unless there's a reason to do so. I think there's a middle ground that we may all be able to agree on, I'll 
20170710 12:58:34< DeFender1031> elaborate when I get back.
20170710 13:00:17-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170710 13:00:33-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: Starting a UEFI update]
20170710 13:01:47-!- Kwandulin [~Miranda@p200300760F12B39B85554C55010031CF.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20170710 13:05:51< zookeeper> sure. i think it's irrelevant whether a coder gets icky or fuzzy feelings from looking at a piece of code and seeing that "this is GOOD CODE" or "omg so BAD DESIGN". what matters is whether it's _actually_ helping/hindering anyone.
20170710 13:05:59< zookeeper> if you disregard that, then changing things because of "better design" just becomes a matter of stylistic choice and is functionally no different from changing the code's formatting/indentation style.
20170710 13:06:08< zookeeper> my point is that no matter how much you try to get an answer out of someone, too often you won't get any answer beyond "it's better design" or "i like it better".
20170710 13:06:37< vultraz_iOS> I completely disagree.
20170710 13:06:51< vultraz_iOS> Bad design doesn't live in vacuum.
20170710 13:07:02< vultraz_iOS> Bad design leads to problems
20170710 13:07:23< zookeeper> so you don't think bad design leading to problems doesn't hinder anyone?
20170710 13:07:27< zookeeper> odd
20170710 13:07:32< vultraz_iOS> actually, no, it doesn't lead to problems
20170710 13:07:34< vultraz_iOS> it IS problems
20170710 13:07:38< vultraz_iOS> it IS inefficiency 
20170710 13:07:52< vultraz_iOS> those things are themselves the bad design
20170710 13:07:55< zookeeper> well, there we go again
20170710 13:08:43< vultraz_iOS> zookeeper: you just asked me if I think bad design leading to problems hinders people :|
20170710 13:08:49-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170710 13:09:35< vultraz_iOS> of course problems from bad design hinders people
20170710 13:09:41< vultraz_iOS> hinder*
20170710 13:10:04< vultraz_iOS> zookeeper: bad design by definition hinders
20170710 13:10:09< vultraz_iOS> Because it's bad!
20170710 13:10:12< zookeeper> ^
20170710 13:10:29< vultraz_iOS> if it were good design it would NOT hinder!
20170710 13:11:11< vultraz_iOS> so I really don't understand your point
20170710 13:16:07< Bonobo> <peanut gallery comment> "good design" and efficiency don't always go hand in hand for at least the wesnoth user interface these days. Case in point -> no longer being able to deselect units with left click </peanut gallery comment>
20170710 13:17:47< zookeeper> vultraz_iOS, if we're fortunate, DeFender1031 might upon his return feel like trying to explain it differently.
20170710 13:23:28-!- RatArmy_ [~ratarmy@om126234114136.16.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 13:27:28-!- Bonobo [~Bonobo@203.63.51.218] has quit [Ping timeout: 246 seconds]
20170710 13:35:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170710 13:35:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 13:50:03-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Ping timeout: 255 seconds]
20170710 13:58:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170710 13:59:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 14:25:33-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170710 14:26:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 14:29:21-!- Kwandulin [~Miranda@p200300760F12B39BC5381FB25D4B48E1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170710 14:51:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170710 14:51:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 14:52:00-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20170710 14:56:29-!- Kwandulin [~Miranda@p200300760F12B39BC5381FB25D4B48E1.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
20170710 15:01:54-!- Kwandulin [~Miranda@p200300760F12B39BC5381FB25D4B48E1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170710 15:08:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170710 15:22:08< DeFender1031> zookeeper, I hope that wasn't sarcasm...
20170710 15:22:24< zookeeper> nope
20170710 15:22:55< DeFender1031> Anyway, yes, I'd like to try to explain it differently, as well as propose a compromise that I hope will satisfy everyone.
20170710 15:33:00< DeFender1031> So I think we all agree that old, more poorly designed stuff should still be operational for at least some amount of time after a new, feature-equivalent approach is introduced, and the amount of time that people seem to be agreeing upon is one major version release after deprecation.Anyway, yes, I'd like to try to explain it differently, as well as propose a compromise that I hope will satisfy everyone.
20170710 15:33:19< DeFender1031> er... don't know how my previous line got repeated there...
20170710 15:33:50< DeFender1031> but anyway, the conflict is over whether/when old stuff should be removed.
20170710 15:35:14< DeFender1031> The vultraz side of the argument would say that old stuff can prevent the expansion of new stuff in two ways:
20170710 15:36:52< DeFender1031> 1. There may be architectural changes one would want to make where the old method's square peg structure no longer fits the new method's round hole structure.
20170710 15:37:09< DeFender1031> 2. if the compatibility code isn't just a simple wrapper/transformation from the old to the new, then any update to whatever system will require updates to both the new, cleaner design, and the older, poorly structured one
20170710 15:38:33< DeFender1031> The zookeeper side of the argument would say "all that is true, but don't remove stuff just because one of those two things COULD in theory end up happening, only remove stuff if such cases actually ARE encountered.
20170710 15:40:12< DeFender1031> The vultraz side would say "but that's just going to hold everything back, because at the point where it becomes clear that the development we want to do will cause the need for such removal, we already want to be writing the code and don't want to have to deprecate and wait for a whole major release before doing so."
20170710 15:41:24< DeFender1031> The zookeeper side would say "but removing every old paradigm just because we like a new design better is going to cause far more work for content creators who want to update their stuff, when it's likely that 90% of the stuff you want to remove won't actually run into cases where it'll be impossible to keep as such."
20170710 15:42:36< DeFender1031> Essentially, there are two practical concerns here which conflict with each other: 1. minimizing work for content creators when porting from one version to another 2. minimizing work and wait times for developers trying to implement new features.
20170710 15:42:46< DeFender1031> Everyone with me so far? vultraz_iOS? zookeeper?
20170710 15:43:10< vultraz_iOS> Yes
20170710 15:43:44< DeFender1031> Have I more or less summarized the arguments on both sides?
20170710 15:44:00< DeFender1031> Or, I suppose, on your side, since that's the only one you can confirm as correct?
20170710 15:45:23< zookeeper> yeah, fair enough
20170710 15:46:46< DeFender1031> So my proposal is this:
20170710 15:47:33< DeFender1031> 1. Any time a new, better design is created, the old one is IMMEDIATELY deprecated. (zookeeper, keep your shirt on, I said deprecated, not removed.)
20170710 15:49:09< DeFender1031> 2. Deprecated designs are to be kept around INDEFINITELY, until they either become time-consuming to maintain or impossible to fit into newer architecture. In addition, they must be kept around for AT LEAST one major release, but as said, preferably longer.
20170710 15:50:09< DeFender1031> 3. Deprecation messages should appear in-game in debug mode ONLY, (and always on the command-line) and should say something to the effect of "this feature, while it may continue to work, may be removed at any time after the next release" if they've just been deprecated, or else just "without warning" if they were deprecated more than one release ago.
20170710 15:51:49< DeFender1031> 4. Compatibility code should prefer simple wrappers, parsers which translate from one syntax to the other, and things of that nature where possible rather than working with the system directly, to try to cut down on how much maintenence they will need if the new design is updated.
20170710 15:53:11< vultraz_iOS> Seems reasonable, but I'd propose a change to point #2. Indefinitely seems to open the door to keeping too many things around simply because they can be. I suggest a minimum of one stable series and no more than 2.
20170710 15:54:04< vultraz_iOS> For example, an API present in 1.12 and deprecated in 1.13 could be removed in 1.15 but no later than 1.17
20170710 15:54:44< DeFender1031> For example, (and assume for the moment that this example doesn't have the question of "should we maintain things introduced in dev releases" which is a separate question) if merging SCALE_SHARP and SCALE to take an optional method parameter, SCALE_SHARP could either be kept around in the form of doing the scale code, or in terms of any SCALE_SHARP(whatever) being internally converted to a SCALE(whatever, sharp), the latter 
20170710 15:54:46< DeFender1031> would be preferred.
20170710 15:55:06< DeFender1031> This way, we can prefer new designs, give the longest possible grace period for old ones, and still be free to remove the things that need removal at the point in time when their removal becomes relevant.
20170710 15:55:23< vultraz_iOS> yes, I fully agree with that
20170710 15:55:27< DeFender1031> vultraz_iOS, I'd ask why you'd be opposed to keeping them around indefinitely if they're not interfering with anything?
20170710 15:55:41< vultraz_iOS> I don't like clutter.
20170710 15:55:44< vultraz_iOS> :P
20170710 15:56:11< vultraz_iOS> Also, why deprecate something if you never remove it?
20170710 15:56:28< DeFender1031> Compatibility code (especially the simple wrappers that would be preferred in such cases) can usually be organized in such a way that it's isolated from everything else and therefore not clutter the rest of the code.
20170710 15:56:43< vultraz_iOS> If something is deprecated it's essentially slated for removal. Keeping deprecated material around indefinitely basically encourages creators to ignore deprecation 
20170710 15:56:51< zookeeper> well, indefinitely sounds like a strong word even for me, but considering that would only apply when 1) it's not getting in anyone's way and 2) it'd be easy to remove if it starts getting in someone's way, it doesn't have any downsides.
20170710 15:57:11< vultraz_iOS> "Eh, this says deprecated, but it still works, so I'll leave it"
20170710 15:57:19< DeFender1031> vultraz_iOS, "why deprecate something if you never remove it?" because of the fundamental issue on YOUR side of the conflict, namely that in case it ever needs removing, it can be removed immediately when needed and not need to wait for a deprecation period then.
20170710 15:57:54< vultraz_iOS> i don't follow
20170710 15:58:03< DeFender1031> vultraz_iOS, I'd argue that it doesn't encourage them to ignore deprecation so much as it allows them to update the more immediately relevant pieces first.
20170710 15:58:22< DeFender1031> okay, we're splitting into two different conversations here now, let me address one at a time.
20170710 15:58:26< vultraz_iOS> DeFender1031: and how do they know what's relevant?
20170710 15:58:51< vultraz_iOS> How do they know feature A will be removed as soon as permissible and feature B will sit around forever.
20170710 15:59:13< vultraz_iOS> either we need levels of deprecation or a hard limit.
20170710 15:59:13< DeFender1031> one at a time. which should we discuss first, why to deprecate and never remove, or how it affects content creators?
20170710 15:59:35< vultraz_iOS> latter essentially answers the former so let's start there
20170710 16:00:27< DeFender1031> Okay.
20170710 16:02:17< DeFender1031> My point is that if there could be, say, a dozen different WML tags, WFL functions, variables, and what-have-you that the newest development has come up with better designs for. If I'm a content creator, each of those could be used in 100 different places in my code, right?
20170710 16:02:38< DeFender1031> So that's 1200 places in the code that I'd need to update if all of those old methods are removed.
20170710 16:04:17< DeFender1031> Let's say I created this code on a hypothetical future version 1.16.
20170710 16:04:43< DeFender1031> None of what I did was deprecated on 1.16
20170710 16:04:52< DeFender1031> However, 1.18 deprecates that stuff.
20170710 16:05:57< DeFender1031> if 1.20 removes all of that, it means that I need to update 1200 different places in my code by the time it comes out, or the whole thing stops working immediately.
20170710 16:06:41< DeFender1031> If, instead, 1.20 required updating only, say, 300 places, and then 1.22 required updating 200 places, etc. that would be a lot more manageable to keep things in working order.
20170710 16:07:10< DeFender1031> Obviously I'm not going to continue to use the deprecated stuff for the new parts of my add-on that i'm creating
20170710 16:07:45< DeFender1031> but forcing me to update ALL the existing parts of my add-on at once (and then do it again the next release) makes it very frustrating to create stuff.
20170710 16:08:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170710 16:08:25< DeFender1031> As for how a content creator knows what's critical to update and what's not, it'll be abundantly clear what has stopped working when whatever release comes out.
20170710 16:09:07< DeFender1031> But my point is, yes, there will be some things that people will be forced to update, but the least they're forced to update, the better.
20170710 16:09:41< DeFender1031> I'm not really worried that people will continue to create NEW stuff using deprecated code. You do that, you're a moron and it's your own fault.
20170710 16:10:23< DeFender1031> But there's a lot of EXISTING stuff that would be time consuming to update all of, especially since it's likely to happen again in the following release.
20170710 16:10:41< vultraz_iOS> alright, you make a good point
20170710 16:11:32< DeFender1031> Eventually, a content creator ends up spending all of their time trying to update their existing code for a new version, and trying to stay ahead of the need to update it again for the next, and essentially gets all the time they would have to actually work on new content eaten up by it.
20170710 16:12:37< vultraz_iOS> I concede the point to you, so I guess I suppose your proposal wholly.
20170710 16:13:41< DeFender1031> For the record, I agree with you about clutter. I hate clutter too. There's tons of stuff that I see that's like "that's really idiotic and were it being implemented fresh right now, I would be against it existing in any form". However, the desire for "only good code" needs to be balanced against the workload and frustration level of the rest of the community.
20170710 16:14:42< DeFender1031> Wonderful.
20170710 16:14:58< vultraz_iOS> Though what if compatibility cannot be maintained at all
20170710 16:15:22< DeFender1031> As I said, that's a valid case for things to be removed.
20170710 16:15:50< DeFender1031> (So long as there has been one release cycle in the interim while it's been deprecated.)
20170710 16:16:18< vultraz_iOS> No, I mean what if a new change means a certain feature cannot be maintained under any circumstances
20170710 16:16:25< vultraz_iOS> For any length of deprecation time.
20170710 16:16:57< DeFender1031> I'd estimate though that about 90% of the "gross, old designs" could be maintained indefinitely with a simple compatibility layer. That translates to a 90% decrease in the work for a content creator to update their code.
20170710 16:17:01< DeFender1031> Oh, that's what you mean.
20170710 16:17:25< DeFender1031> Well, if I'm going write up my proposal into a formal policy draft, I'd make allowances for that.
20170710 16:17:41< vultraz_iOS> Please do draft.
20170710 16:18:19< vultraz_iOS> What I want to avoid is a situation where we opt for maintaining existing functionality over new functionality if there is a compelling reason to use the new functionality but old functionality cannot be maintained.
20170710 16:19:25< DeFender1031> Though, I'd say that in general, if something new comes up where a massive, sweeping design change would make it impossible to maintain an older paradigm, it would probably be best to try to make the change gradually over the course of a couple of releases rather than all at once unless the change is so radically different that it would be impossible to have the two coexist for any amount of time.
20170710 16:19:56< vultraz_iOS> I think immediate removal would be acceptable in such cases.
20170710 16:20:07< vultraz_iOS> Deprecation is really just about giving people time to update their work.
20170710 16:20:20< vultraz_iOS> A 0-length period basically means "you must update IMMEDIATELY"
20170710 16:20:31< DeFender1031> Me too, so long as there was broad consensus among the devs that such change is a major improvement.
20170710 16:21:35< zookeeper> cases where you really need to perform an immediate removal like that would be pretty exceptional anyway.
20170710 16:21:39< vultraz_iOS> Yes
20170710 16:22:52< vultraz_iOS> just as long as we acknowledge they could happen,
20170710 16:24:52< DeFender1031> So essentailly, we're talking about 3 levels of deprecation here. In order of how often they should be used: 1. Deprecated but still maintained via a wrapper indefinitely. Should not be used for new development, as they may be removed at any time and creating new stuff with them will add porting work down the line, but they will likely keep working for the forseeable future and allow you time to update existing code at your 
20170710 16:24:54< DeFender1031> leisure. 2. Deprecated for removal. A new paradigm means that this will no longer be feasible in the next release, update before then. Should only be used when something is actually going to become infeasible. 3. Immediate change. USE EXTREMELY RARELY. Some important architecture change means that there is no way to transition from the old method to the new except cold turkey. Requires developer consense.
20170710 16:24:59< DeFender1031> consensus*
20170710 16:25:58< DeFender1031> And any change should aim for the lowest level of deprecation possible.
20170710 16:26:22< zookeeper> anyway, the proposal seems good to me, as long as point 1 isn't used as a catch-all for removing stuff that really doesn't get in anyone's way (for example macros which could now be replaced with new tags etc).
20170710 16:26:53< vultraz_iOS> Seems good to me.
20170710 16:26:59< DeFender1031> If some dev thinks a level 2 or 3 is necessary, others should attempt to come up with creative solutions, etc.
20170710 16:27:47< zookeeper> i mean i still don't want anyone insisting that we need to _remove_ FOREACH just because we don't like unbalanced macros and because you _can_ do the same things with the new looping tags. keeping it doesn't get in anyone's way and no one is inconvenienced if their old code that uses it keeps working instead of forcing them to replace it with a [foreach].
20170710 16:28:07< DeFender1031> zookeeper, I have no problem with deprecating macros which now have tags for them by wrapping them to those tags, removing them from the documentation, and adding a deprecation notice. However, those are VERY good examples of things which will likely NEVER actually need to be removed, since they can always continue to wrap to the tags.
20170710 16:28:09-!- Kwandulin [~Miranda@p200300760F12B39BC5381FB25D4B48E1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170710 16:30:03< zookeeper> DeFender1031, well yeah, if/when the deprecation notices don't bother casual players then sure
20170710 16:30:09< vultraz_iOS> Well, it doesn't wrap the tag per-se, but alright
20170710 16:31:21 * zookeeper is afk
20170710 16:31:42< vultraz_iOS> I wonder what we would do in the case of, say, throwing out the preprocessor.
20170710 16:32:58< Soliton> sounds like level 2.
20170710 16:33:15< vultraz_iOS> yeah
20170710 16:35:20< DeFender1031> vultraz_iOS, some may, some may not. The point is, it's not hard to keep a bunch of old macros around. They don't really need updating, they're just there and htey work.
20170710 16:35:34< DeFender1031> vultraz_iOS, what do you mean "throwing out the preprocessor"?
20170710 16:37:25< vultraz_iOS> I don't really know.
20170710 16:37:25< DeFender1031> zookeeper, well, that's the thing. We'll need a simple function in WML, C++, and Lua which takes a deprecation notice string and a version number and basically prints the notice to the command-line as well as, if debug mode is on, the in-game text display. That function should be ridiculously simple to write.
20170710 16:37:45< vultraz_iOS> i think it exists already
20170710 16:38:13< DeFender1031> If it exists, also wonderful. Though if it shows messages to players when not in debug mode, that's a problem.
20170710 16:38:53< DeFender1031> Anyway, I'm gonna write this up. Should I make it a wiki page, a forum post, a forum post linking to a wiki page?
20170710 16:39:31< vultraz_iOS> wiki page for now
20170710 16:39:50< vultraz_iOS> post it on the forums and the peanut gallery will descend
20170710 16:40:14< DeFender1031> Okay. Name: "CompatibilityPolicy" sound okay? 
20170710 16:40:44< vultraz_iOS> sure
20170710 16:46:12< DeFender1031> Or "CompatibilityStandards" to match "CodingStandards"
20170710 16:50:53< vultraz_iOS> alright
20170710 17:14:25-!- Duthlet [~Duthlet@ipservice-092-211-172-179.092.211.pools.vodafone-ip.de] has quit [Ping timeout: 276 seconds]
20170710 17:25:24-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170710 17:27:04-!- RatArmy_ [~ratarmy@om126161114090.8.openmobile.ne.jp] has joined #wesnoth-dev
20170710 17:27:44-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170710 17:37:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170710 17:37:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170710 17:37:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170710 17:37:51-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170710 17:38:11-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170710 17:38:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170710 17:43:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 255 seconds]
20170710 17:43:09-!- RatArmy_ [~ratarmy@om126161114090.8.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 17:53:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170710 17:54:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170710 17:56:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170710 18:06:03-!- pedro4 [sid145515@gateway/web/irccloud.com/x-nuylbwtnyviyrbnk] has joined #wesnoth-dev
20170710 18:08:33-!- pedro4 [sid145515@gateway/web/irccloud.com/x-nuylbwtnyviyrbnk] has quit [Client Quit]
20170710 18:08:43-!- pedro4 [sid145515@gateway/web/irccloud.com/x-vkfpridldpcknswv] has joined #wesnoth-dev
20170710 18:10:04-!- Kwandulin [~Miranda@p200300760F12B39B1DE523B40493CDA0.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170710 18:25:04-!- mjs-de [~mjs-de@dorf.cc] has joined #wesnoth-dev
20170710 18:37:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170710 18:37:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170710 18:38:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 18:43:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170710 18:51:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170710 18:55:04-!- pedro4 [sid145515@gateway/web/irccloud.com/x-vkfpridldpcknswv] has quit []
20170710 18:56:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170710 19:00:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170710 19:08:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170710 19:14:07-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20170710 19:19:13-!- Kwandulin [~Miranda@p200300760F12B39B1DE523B40493CDA0.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds]
20170710 19:20:38-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 19:33:03-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170710 19:54:05-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 20:00:59-!- zookeeper_ [~lmsnie@95.175.104.51] has joined #wesnoth-dev
20170710 20:01:51-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Disconnected by services]
20170710 20:01:54-!- zookeeper_ is now known as zookeeper
20170710 20:01:55-!- zookeeper [~lmsnie@95.175.104.51] has quit [Changing host]
20170710 20:01:55-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170710 20:34:09-!- mjs-de [~mjs-de@dorf.cc] has quit [Ping timeout: 255 seconds]
20170710 20:41:21-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 20:48:13-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 258 seconds]
20170710 20:57:06-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 20:59:49-!- gfgtdf [~chatzilla@x4e363786.dyn.telefonica.de] has joined #wesnoth-dev
20170710 21:16:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds]
20170710 21:17:02-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 21:18:35< DeFender1031> Nearly done, heading to bed, will finish and post tomorrow.
20170710 21:25:48-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20170710 21:35:51-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2907:ce45:2c43:8f4f] has joined #wesnoth-dev
20170710 21:37:47-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2907:ce45:2c43:8f4f] has quit [Remote host closed the connection]
20170710 21:38:03-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2907:ce45:2c43:8f4f] has joined #wesnoth-dev
20170710 22:08:02-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 22:08:53< zookeeper> gfgtdf, oh you're back?
20170710 22:17:40< gfgtdf> zookeeper: ye
20170710 22:19:18-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:2907:ce45:2c43:8f4f] has quit [Remote host closed the connection]
20170710 22:24:09-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 22:43:29-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170710 22:47:43-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170710 22:48:31< Coffee_irc> ping gfgtdf - do you have a couple of minutes?
20170710 22:51:19-!- irker311 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170710 22:51:19< irker311> wesnoth: gfgtdf wesnoth:master b68a23c4802e / src/gui/dialogs/unit_advance.cpp: attempt to fix issue #1820 https://github.com/wesnoth/wesnoth/commit/b68a23c4802e13121836df88ea353db7d01ad3bb
20170710 22:51:56< gfgtdf> Coffee_irc: ye
20170710 22:52:02< Coffee_irc> hi gfgtdf
20170710 22:52:07< gfgtdf> hi
20170710 22:52:24< Coffee_irc> I assigned you a bug https://github.com/wesnoth/wesnoth/issues/1565
20170710 22:52:40< Coffee_irc> because I am generous :)
20170710 22:52:47< Coffee_irc> and wanted to give you something
20170710 22:53:32< Coffee_irc> don't know if you've had a chance to look at this?
20170710 22:53:58< gfgtdf> Coffee_irc: no i just came back
20170710 22:54:12< Coffee_irc> specifically the lua changes to game_events/pump.cpp concern me
20170710 22:54:15< vultraz_iOS> wb
20170710 22:54:36< gfgtdf> Coffee_irc: but i dont really know the animation code but i can take a look at the lua/pump code.
20170710 22:55:01< Coffee_irc> basically there is a bit of code there (one line) that causes trouble for me to fix a bug with animations
20170710 22:55:11< Coffee_irc> and wonder if you could recview it
20170710 22:55:47< Coffee_irc> line 567 ++impl_->internal_wml_tracking;
20170710 22:56:13< Coffee_irc> as per the bug report this causes movement animations to not work properly over more than one hex movements
20170710 22:57:04< Coffee_irc> there is a separate bug to be fixed, but I can try to take that on and would very much appreciate if this could be changed in master
20170710 22:57:42< gfgtdf> Coffee_irc: i didn't really change the ++impl_->internal_wml_tracking; line although i intended (and still inted) to do so
20170710 22:57:52< Coffee_irc> can it just be removed?
20170710 22:58:07< gfgtdf> Coffee_irc: i did 2ff22bae3691f821a61dd9bf3e5c1cb4ee37f5f8 whihc just adds a level of indention
20170710 22:58:17< Coffee_irc> oh, ok
20170710 22:58:23< gfgtdf> Coffee_irc: and 4fe20fd125a8f7a1244cd1d87de058f26548958c which just addsa  comment
20170710 22:58:31< Coffee_irc> sorry for blaming you for this then :P
20170710 22:58:42< Coffee_irc> that is git-blame
20170710 22:59:12< gfgtdf> Coffee_irc: but as mentione din the comment i think there is no point in the internal_wml_tracking variable anymore.
20170710 22:59:21< Coffee_irc> let's remove it then
20170710 23:00:08< gfgtdf> Coffee_irc: as said in the comment is used in the movement code for some caching of paths.
20170710 23:00:32< Coffee_irc> maybe comment it out with a note that it causes problems with movement animations?
20170710 23:00:50< gfgtdf> Coffee_irc: removing the internal_wml_tracking variable makes onyl sense with removing that 'optimsisation' at the same time.
20170710 23:01:04< gfgtdf> Coffee_irc: and the movement code is rather complicated.
20170710 23:01:13< Coffee_irc> yeah, I know
20170710 23:01:27< Coffee_irc> I'm trying to solve a problem where the movments can be jerky
20170710 23:01:34< gfgtdf> Coffee_irc: just removiong the ++internal_wml_tracking line might cause wrong bahjviour in case that a lua event changes the location on units in a moveto event.
20170710 23:02:57< Coffee_irc> gfgtdf: do you have an idea on how to fix this?
20170710 23:03:39-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170710 23:04:03< gfgtdf> Coffee_irc: does this lag only applear with addons or also with mainline multiplayer?
20170710 23:04:14< Coffee_irc> gfgtdf: this is not a lag issue
20170710 23:04:25< Coffee_irc> basically this is a "precursor" problem
20170710 23:04:32< Coffee_irc> there are many issues here
20170710 23:04:46-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170710 23:04:47< Coffee_irc> this lua thing though causes movment animations to not work
20170710 23:04:54< Coffee_irc> even at 1x speed
20170710 23:05:10< Coffee_irc> aesy to see with any of the drakes
20170710 23:05:15< Coffee_irc> *easy
20170710 23:08:05< Coffee_irc> you can see the proper animation on "undo" though with the lua code in place
20170710 23:08:11< Coffee_irc> for comparison
20170710 23:13:07< gfgtdf> Coffee_irc: i think that this code: https://github.com/wesnoth/wesnoth/blob/1.13.8/src/actions/move.cpp#L548
20170710 23:13:44< gfgtdf> Coffee_irc: is someow unsuit.ed it seems like whnever there happed a wml event
20170710 23:13:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170710 23:14:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170710 23:14:08< gfgtdf> Coffee_irc: the animator is told to reset the current unit which somehow also resets the state of the animation
20170710 23:14:33< Coffee_irc> which is what you want
20170710 23:14:34< gfgtdf> Coffee_irc: it could be possible to have a way to have wml events involved without ruining the animation.
20170710 23:14:39< Coffee_irc> in case of ambush, etc.
20170710 23:14:43< gfgtdf> should*
20170710 23:15:32< gfgtdf> Coffee_irc: this code assumes that all wml events somehow disturb movement, even thought they coudl for exampel just updates an internal wml varibale that tracks the location of the unit
20170710 23:15:33< Coffee_irc> the lua events are fired all the time
20170710 23:17:08-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 23:17:12< Coffee_irc> gfgtdf: I would think it is a safe assumption that this works in wml events
20170710 23:17:33< Coffee_irc> you can only run code when the unit moves to a new hex, etc. anyway
20170710 23:17:35< gfgtdf> Coffee_irc: what do you mean exactly?
20170710 23:17:59< Coffee_irc> from wml "[fire_event]" or "[event]"
20170710 23:18:09< Coffee_irc> which is what I think you mean?
20170710 23:19:46< Coffee_irc> I think this actually makes sense
20170710 23:20:50< gfgtdf> i dont tihnk this issue is speciifc to lua evenbtz,s you coudl probalby ghet the same issues with a wml event like this: https://pastebin.com/4ACdaGQh
20170710 23:20:57< Coffee_irc> if I had some WML code that fired on a move to hex I wouldn't want the unit to be animating like a horseman moving on the spot
20170710 23:21:05< gfgtdf> actuall i forgot the allow_undo in there
20170710 23:21:31< gfgtdf> Coffee_irc: why woudl it move on the spot?
20170710 23:21:43< gfgtdf> Coffee_irc: the wml event finished inniditeley
20170710 23:22:15< Coffee_irc> gfgtdf: what if it started another fake unit animation movement?
20170710 23:22:44< Coffee_irc> gfgtdf: ok
20170710 23:23:23< Coffee_irc> then the code needs exceptions for the "update" parameter for these enter_hex,exit_hex events
20170710 23:23:28< gfgtdf> Coffee_irc: it could, i didnt say that wml events shoudl never abort the animation, but assuming that it shodul _always_ abort that animation shoudl seems wrong aswell
20170710 23:23:34< Coffee_irc> and for lua equivalents
20170710 23:23:56-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170710 23:24:45-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170710 23:25:03< gfgtdf> Coffee_irc: this somhow requiresa additional checking or wml syntax, we coudl for example mayne have some wesnoth.abort_current_movenent_animation lua function that is automatically called by some wml tags
20170710 23:26:02< Coffee_irc> gfgtdf: maybe it will just work if the code gets changed to check for these enter_hex,exit_hex events?
20170710 23:26:47-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170710 23:27:24< Coffee_irc> I don't really understand the lua stuff to be honest
20170710 23:27:40< Coffee_irc> and don't know how to make the check for the appropriate events
20170710 23:28:48-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds]
20170710 23:29:52< gfgtdf> Coffee_irc: well is not easy, i mena of course exit/entger hex event can also so fancy stufff even adding/removing unit animations so we probabyl do need careful checking 
20170710 23:30:15< Coffee_irc> I thought so as well
20170710 23:30:47< Coffee_irc> but maybe this is for a future obscure bug report and we can just get it working 99% of the time
20170710 23:31:04< gfgtdf> hmm have to go to bed now. will think about it tomorrow
20170710 23:31:10< Coffee_irc> and just do a basic check
20170710 23:31:15< Coffee_irc> np
20170710 23:31:37< Coffee_irc> gfgtdf: thanks for your time today
20170710 23:31:42< Coffee_irc> have a good night
20170710 23:31:49< gfgtdf> thx
20170710 23:31:51-!- gfgtdf [~chatzilla@x4e363786.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 54.0/20170608105825]]
20170710 23:34:11-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170710 23:35:33< irker311> wesnoth: Charles Dang wesnoth:accelerated_rendering 65c57fd9cbd2 / src/display.cpp: Display: re-enable fps counter with :fps https://github.com/wesnoth/wesnoth/commit/65c57fd9cbd2c711cd02c92053a6a5f79e0f4c4c
20170710 23:36:00-!- Bonobo [~Bonobo@203.63.51.218] has joined #wesnoth-dev
20170710 23:45:18-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has joined #wesnoth-dev
20170710 23:46:23-!- Polsaker is now known as Polesaker
20170710 23:51:34-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
--- Log closed Tue Jul 11 00:00:31 2017