--- Log opened Mon Jan 08 00:00:34 2018
20180108 00:05:48-!- ChipmunkV[m] [chipmunkvm@gateway/shell/matrix.org/x-xateckeymfwessib] has quit [Read error: Connection reset by peer]
20180108 00:05:49-!- syrma[m] [syrmamatri@gateway/shell/matrix.org/x-wogmwmastiajmsvq] has quit [Read error: Connection reset by peer]
20180108 00:05:56-!- madmax28 [madmax28ma@gateway/shell/matrix.org/x-pdtcjgssxsychdtw] has quit [Remote host closed the connection]
20180108 00:05:57-!- zacklocx[m] [zacklocxma@gateway/shell/matrix.org/x-uiiwpucftfypauyf] has quit [Remote host closed the connection]
20180108 00:13:41-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20180108 00:13:57-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20180108 00:15:01-!- zacklocx[m] [zacklocxma@gateway/shell/matrix.org/x-jhlhvaozwwpqewta] has joined #wesnoth-dev
20180108 00:29:53-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Ping timeout: 248 seconds]
20180108 00:32:39-!- madmax28 [madmax28ma@gateway/shell/matrix.org/x-hkssflplihdqqzwe] has joined #wesnoth-dev
20180108 00:32:39-!- ChipmunkV[m] [chipmunkvm@gateway/shell/matrix.org/x-gpntegtrnhtbnptf] has joined #wesnoth-dev
20180108 00:32:46-!- syrma[m] [syrmamatri@gateway/shell/matrix.org/x-yrrbcxokkszdslsg] has joined #wesnoth-dev
20180108 00:38:45-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20180108 00:44:21-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Ping timeout: 246 seconds]
20180108 00:56:52-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20180108 01:01:19-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Read error: Connection reset by peer]
20180108 01:03:01-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20180108 01:07:10< irker297> wesnoth: Gunter Labes wesnoth:master 3fa5272737e8 / src/ (gui/dialogs/multiplayer/player_list_helper.cpp server/game.cpp): Avoid useless user list sending https://github.com/wesnoth/wesnoth/commit/3fa5272737e8feab4d427d204168a586f0d9ee5e
20180108 01:07:12< irker297> wesnoth: Gunter Labes wesnoth:master 15059ec10c9e / src/ (3 files in 2 dirs): Revert network protocol change from 002b1a3c87 https://github.com/wesnoth/wesnoth/commit/15059ec10c9ec528ba0305bb87e704508b6d563c
20180108 01:08:42-!- Porusaka is now known as Polsaker
20180108 01:10:00-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has joined #wesnoth-dev
20180108 01:13:48-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20180108 01:14:28-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has quit [Ping timeout: 255 seconds]
20180108 01:28:45-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has joined #wesnoth-dev
20180108 01:32:39< Ravana_> does any Lua unit creation function accept equivalent of placement = "map_passable" ?
20180108 01:39:07-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 265 seconds]
20180108 01:43:20-!- tomreyn_ [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20180108 01:43:27-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Ping timeout: 248 seconds]
20180108 01:52:27-!- tomreyn_ [~tomreyn@megaglest/team/tomreyn] has quit [Ping timeout: 240 seconds]
20180108 02:06:19-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20180108 02:22:18-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20180108 02:47:43< Ravana_> chat showing lua error, but stderr has nothing about that
20180108 02:49:04< celticminstrel> Oh yeah, I wanted to comment here. Hm.
20180108 02:49:23< celticminstrel> I guess the Lua create_unit function doesn't pass through the unit_creator...?
20180108 02:49:59< celticminstrel> Which would probably mean the only solution currently is to use one of the pathfinding functions to manually find a viable location.
20180108 02:50:08< celticminstrel> Or something along those lines.
20180108 02:50:22< celticminstrel> (It's the unit_creator that interprets the placement key.)
20180108 02:50:54< celticminstrel> But perhaps it would be better to use the unit_creator function in create_unit.
20180108 02:51:08< celticminstrel> (By which I mean changing the source.)
20180108 02:51:24< celticminstrel> ISTR gfgtdf might've considered it at one point, too.
20180108 02:54:50< Ravana_> I guess I need to continue with wesnoth.fire("unit") then
20180108 02:55:21< celticminstrel> That's probably the only way to invoke the unit_creator from Lua ATM, yeah.
20180108 02:55:33< celticminstrel> Well, that or the nearly-equivalent wesnoth.wml_actions.unit.
20180108 02:55:45< celticminstrel> (The only difference being that the latter doesn't substitute WML variables.)
20180108 02:56:22< Ravana_> been using wesnoth.fire mostly because its shorter
20180108 02:56:38< celticminstrel> (The fire function is literally function fire(tag, cfg) wesnoth.wml_actions[tag](cfg.__parsed) end IIRC)
20180108 04:08:16-!- irker297 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20180108 04:12:56-!- irker927 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20180108 04:12:56< irker927> wesnoth: Celtic Minstrel wesnoth:master b069bdd16e4d / src/addon/client.cpp: fixup a4e7cb01e81962ab313884ba9df6ecc35ebbe4a3 https://github.com/wesnoth/wesnoth/commit/b069bdd16e4d189d266b48767da8109b1d0d0fa7
20180108 04:20:29-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20180108 04:20:43< vultraz> oh for...
20180108 04:20:49< vultraz> WHY
20180108 04:22:49-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:88fb:1a7f:c783:4ede] has joined #wesnoth-dev
20180108 04:23:40< celticminstrel> ?
20180108 04:23:48< celticminstrel> Something wrong, vultraz?
20180108 04:23:53< vultraz> 3fa5272737e8  and 15059ec10c9e 
20180108 04:24:00< vultraz> former, fine. I don't like it, but fine
20180108 04:24:02< vultraz> but the second?
20180108 04:24:17< vultraz> You could just make it so [userlist] is used everywhere
20180108 04:24:19< celticminstrel> Oh, Soliton's revert of the protocol change.
20180108 04:24:32< celticminstrel> Well, TBH it's silly to make useless changes to the protocol.
20180108 04:24:44< celticminstrel> You don't gain anything by changing it to [userlist].
20180108 04:25:01< vultraz> then let's get rid of [gamelist]
20180108 04:25:17< celticminstrel> That's almost certainly the same thing - you don't gain anything.
20180108 04:25:33< celticminstrel> And in theory it could cause problems.
20180108 04:26:26< celticminstrel> (By which I mean development problems if you need to connect an older version of the client to the latest server, or vice versa.)
20180108 04:27:17< celticminstrel> (Worst case, inability to connect to the server at all until it's rebuild for the next minor release.
20180108 04:27:18< celticminstrel> )
20180108 04:27:39-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:88fb:1a7f:c783:4ede] has quit [Ping timeout: 246 seconds]
20180108 04:28:01< celticminstrel> (Though looking at the specific commit, the worst case probably wouldn't happen in this specific scenario.)
20180108 04:28:05< celticminstrel> ^-probably
20180108 04:29:06< celticminstrel> As an aside, I'll note that changing save file or preferences format on a whim is a similarly bad idea, thought not quite as bad.
20180108 04:30:04< celticminstrel> Still, the best-case scenario with save files is that any version of the game can load a save file from any earlier version. :P
20180108 04:30:26< celticminstrel> This becomes more important when you have automatic updates.
20180108 04:38:39< vultraz> we do not support connecting older versions of a client to a newer serve
20180108 04:38:42< vultraz> r
20180108 04:39:05< celticminstrel> It's not really about whether we officially support it or not, it's about whether it could interfere with testing.
20180108 04:40:01< vultraz> what testing>
20180108 04:40:03< vultraz> ?
20180108 04:40:06< celticminstrel> Sometimes you can't avoid changing the protocol in an incompatible way. That's fine. But if you can avoid it, you might as well do so, because you never know if that compatibility might help people to test something or other.
20180108 04:40:27< celticminstrel> There are probably other reasons too. Ask Soliton I guess. I need to get to bed.
20180108 04:41:05< celticminstrel> Anyway, just because you don't officially enforce compatibility, that's not a reason to whimsically break compatibility.
20180108 04:41:14-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
20180108 04:46:14< vultraz> *groans*
20180108 05:24:34-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:88fb:1a7f:c783:4ede] has joined #wesnoth-dev
20180108 05:29:31-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:88fb:1a7f:c783:4ede] has quit [Ping timeout: 240 seconds]
20180108 05:31:53-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20180108 06:40:43-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20180108 07:09:45-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20180108 07:12:55-!- irker927 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20180108 07:20:56-!- irker719 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20180108 07:20:56< irker719> wesnoth/wesnoth:master Gunter Labes 15059ec10c Revert network protocol change from 002b AppVeyor: All builds passed
20180108 07:32:58-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20180108 07:40:24< irker719> wesnoth/wesnoth:master Celtic Minstrel b069bdd16e fixup a4e7cb01e81962ab313884ba9df6ecc35e AppVeyor: All builds passed
20180108 08:18:04< vn971> Ravana_: I use a code like this in Creep Wars (do_creep_spawn.lua), it runs OK.. I think:
20180108 08:18:04< vn971> local unit = gen_creep(creep_score) -- only generates the unit, doesn't place it
20180108 08:18:04< vn971> local x, y = wesnoth.find_vacant_tile(spawn_pos[team].x, spawn_pos[team].y, unit)
20180108 08:18:04< vn971> wesnoth.put_unit(unit, x, y)
20180108 08:18:35-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has quit [Ping timeout: 240 seconds]
20180108 08:18:35< vn971> that is, it places a unit only on a passable for said unit terrain (if I get the docs right).
20180108 08:18:46< Ravana_> yes, I mentioned that
20180108 08:19:10-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has joined #wesnoth-dev
20180108 08:26:33< vn971> I wasn't sure, ok.
20180108 09:12:07-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20180108 09:18:25-!- Rhonda [~rhonda@wesnoth/developer/rhonda] has quit [Remote host closed the connection]
20180108 09:22:04-!- Rhonda [~rhonda@anguilla.debian.or.at] has joined #wesnoth-dev
20180108 09:26:28-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:88fb:1a7f:c783:4ede] has joined #wesnoth-dev
20180108 09:31:13< Soliton> vultraz: just to clear up possible confusion, we support any client version connecting to any server version since years. clients just get redirected after we figure out their version.
20180108 09:31:25-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:88fb:1a7f:c783:4ede] has quit [Ping timeout: 252 seconds]
20180108 09:31:39< vultraz> Fair enough
20180108 10:15:34-!- vladimirslavik [vslavik@nat/redhat/x-zehfnayrkjlpcuwk] has joined #wesnoth-dev
20180108 10:15:52-!- vladimirslavik [vslavik@nat/redhat/x-zehfnayrkjlpcuwk] has quit [Changing host]
20180108 10:15:52-!- vladimirslavik [vslavik@wesnoth/translator/VladimirSlavik] has joined #wesnoth-dev
20180108 10:41:51-!- irker719 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20180108 10:51:35-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20180108 11:27:30-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:88fb:1a7f:c783:4ede] has joined #wesnoth-dev
20180108 11:32:10-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:88fb:1a7f:c783:4ede] has quit [Ping timeout: 265 seconds]
20180108 11:40:17-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20180108 12:06:20-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20180108 12:41:03-!- galegosimpatico [~uprego@unaffiliated/ushiu] has quit [Ping timeout: 248 seconds]
20180108 12:48:26-!- galegosimpatico [~uprego@130.red-88-3-143.dynamicip.rima-tde.net] has joined #wesnoth-dev
20180108 13:28:30-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:88fb:1a7f:c783:4ede] has joined #wesnoth-dev
20180108 13:32:52-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:88fb:1a7f:c783:4ede] has quit [Ping timeout: 252 seconds]
20180108 14:40:19-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20180108 15:02:06-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20180108 15:03:27-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 248 seconds]
20180108 15:03:28-!- wedge010 is now known as wedge009
20180108 15:05:23-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20180108 15:16:58-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20180108 15:19:06-!- elias [~allefant@allegro/developer/allefant] has quit [Quit: WeeChat 1.7]
20180108 15:19:29-!- allefant [~allefant@allegro/developer/allefant] has joined #wesnoth-dev
20180108 15:20:55-!- allefant is now known as elias
20180108 15:32:47-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20180108 15:51:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20180108 15:57:14-!- mkdr0id [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20180108 15:59:35-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Ping timeout: 240 seconds]
20180108 16:05:36-!- mkdr0id [~null@unaffiliated/matthiaskrgr] has quit [Remote host closed the connection]
20180108 16:59:23< vn971> UPD on unit.advances_to
20180108 16:59:54< vn971> it sucks. Wesnoth (at least 1.12) enforces no constraints on manipulationg advances_to.
20180108 17:00:23< vn971> I've just invoked a simple OOS by using the "Ageless Era" addon.
20180108 17:02:46< vn971> steps to reproduce: 1. download Ageless addon, start hosting a game with Default Era. 2. Connect with a client that does NOT have Ageless. 3. Recruit a skeleton with the host side and make it advance to "Death Baron". 4. The other player will now report OOS.
20180108 17:03:34< vn971> This happens because Ageless addon is allowed to change stuff, yet the game has no notion of Ageless Era, so clients are not required to have this addon.
20180108 17:04:04< DeFender1031> isn't there a "requires_addon" key that creators are supposed to use if the add on requires all players to have it?
20180108 17:04:52< vn971> DeFender1031: sure is, and Ageless has it, obviously (because of the graphics). BUT then again, the game is played on Default Era, not Ageless Era. So this requirement has no effect.
20180108 17:05:33< DeFender1031> why would ageless be modifying units if it's not the era in use?
20180108 17:05:48< Soliton> what's the difference to editing some unit cfg and change some values?
20180108 17:05:48< vn971> Basically this happens because Ageless leaks its changes outside of its Era.
20180108 17:06:31< DeFender1031> that sounds like Ageless is coded improperly then
20180108 17:06:32< vn971> DeFender1031: good question. But since wesnoth does not enforce anything.. That's just possible.
20180108 17:07:04< vn971> Soliton: was that a question to me? (I don't get it fully if it's for me.)
20180108 17:07:29< Soliton> yes. no idea what to clarify.
20180108 17:07:49< Soliton> sounds to me like that is exactly why we report OOS.
20180108 17:08:16< vn971> Soliton: I don't know what's the difference. I've just written steps how to cause OOS with Ageless Era.
20180108 17:08:37< DeFender1031> vn971, so report it to the mmaintainer of Ageless.
20180108 17:09:35< Soliton> oh, we're not talking about manipulating advances_to. my bad.
20180108 17:09:49< vn971> Soliton: dunno, I like enforcing things. Is there a smarter way out than just introduce mental requirements for Add-on writers?
20180108 17:10:31< Soliton> the issue is still the same though different clients have different unit definitions with the same ID.
20180108 17:10:35< vn971> Soliton: well manipulation of advances_to makes it possible to cause easy OOS with an Era, which is the thing I'm currently trying to understand.
20180108 17:10:51< DeFender1031> add-on code is suppposed to wrap itself inside of a check for its specific macro being defined. It's not hard to get right, and if an add-on is leaking code, it means that it's not done right.
20180108 17:10:52< Soliton> where is the manipulation?
20180108 17:11:12< vn971> Soliton: ah, maybe whole unit replacement then, not manipulation, ok.
20180108 17:11:19< zookeeper> DeFender1031, the point is, until 1.13 there was no way to do that kind of wrapping. all you got for multiplayer content was #ifdef MULTIPLAYER.
20180108 17:11:32< DeFender1031> zookeeper, ah.
20180108 17:11:49< zookeeper> well, i don't know if that was actually anyone's point, but the point stands. :p
20180108 17:12:22< Soliton> it'd be nice to get each addon in its own namespace but that's a major change and then you need to reimplement ways for addons to interact again.
20180108 17:12:32< vn971> ok, I'll hint to my question above more boldly. Can we make wesnoth NOT load an unneeded add-on at all, for a specific game?
20180108 17:12:44< Soliton> no.
20180108 17:12:50< zookeeper> in 1.13 you should be able to do it properly, since you can have era/scenario-specific defines.
20180108 17:13:12< vn971> Like if I'm starting a game with Era ABC and mods 1,2,3, why would wesnoth not load these and only these mods and Era ?
20180108 17:13:30< zookeeper> because that's not how the "loading" works in the first place
20180108 17:13:31< Soliton> because it doesn't work that way.
20180108 17:14:13< vn971> Is it pointless to raise a bug to still work this way?.. Sorry for questioning so sharply, I'm not trying to be hostile or rude.
20180108 17:14:28< zookeeper> there is a way in 1.13
20180108 17:14:58< vn971> just I wonder whether that would be a good goal to achieve. Easier correctness.
20180108 17:15:15< vn971> Enforced correctness of many such situations I would even say.
20180108 17:15:34< zookeeper> a good one, sure, but not exactly easy due to the way things work.
20180108 17:15:58< Soliton> to do it properly, not via the preprocessor, would be nice but a major change that probably needs rewriting of many addons.
20180108 17:16:32< Soliton> (a worthy goal IMO still.)
20180108 17:16:49< vn971> That's sad though. I'm not a CPP dev, but that would taste like usage of static variables/state split across multiple places. Which is... pretty common among many games, unfortunately.
20180108 17:17:32< zookeeper> btw, define= is not documented on https://wiki.wesnoth.org/ScenarioWML and thus probably the same for EraWML
20180108 17:17:41< Soliton> not sure if wildly guessing at some implementation details of a laguage you say you don't know is that useful. :-P
20180108 17:18:11< vn971> (nvm about the code part, anyway. I'm not trying to make any real point here, just a developer woke up in me for a minute.)
20180108 17:18:43< vn971> Soliton: true. OK, so will think about raising a bug then. Thanks for answering.
20180108 17:19:42-!- zookeeper_ [~lmsnie@dsl-tkubng21-58c01f-56.dhcp.inet.fi] has joined #wesnoth-dev
20180108 17:20:00< Soliton> the issue is how WML is used in multiplayer addons. that wesnoth puts everything in one huge document.
20180108 17:20:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20180108 17:20:58< zookeeper_> are you at all familiar with how WML loading works in wesnoth? the way the game knows which eras and scenarios and modifications are present _is_ by loading add-on WML. _then_ it can look at that one huge document it has and see if any of that stuff is for example an era it should include in the era drop-down menu.
20180108 17:21:07< vn971> (Soliton: my guess was: if you can't pre-process & handle a limited set of add-ons over again, then it's most probably because some parts are initialized and kept somewhere. Really, otherwise re-loading would seem like an easy task.)
20180108 17:21:16-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Disconnected by services]
20180108 17:21:19-!- zookeeper_ is now known as zookeeper
20180108 17:21:21-!- zookeeper [~lmsnie@dsl-tkubng21-58c01f-56.dhcp.inet.fi] has quit [Changing host]
20180108 17:21:21-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20180108 17:23:16< Soliton> vn971: you focus on implementation issues but the design is just not modular and you can't just change the design in a heartbeat.
20180108 17:23:55< vn971> zookeeper: yes, true. I could easily imagine a bug-prone algo though which would just eliminate addons that are not needed for a particular game for sure (shouldn't be needed, anyway).
20180108 17:24:08< vn971> Soliton: true.
20180108 17:24:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20180108 17:24:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20180108 17:24:51< vn971> Ok, anyway, the other practical implication for me is that I surely can't trust my code that iterates over Era unit advances anymore. I can only iterate Era leaders and Era recruits, everything else is prone to errors.
20180108 17:24:56< zookeeper> ultimately the game has almost no concept of add-ons (beyond "oh this directory is an add-on"), add-on content is basically just loaded exactly like core content is, and the engine can't automatically make intelligent decisions like when to load add-on A and not B. it just loads them all and the responsibility is on the add-on authors to avoid breakage.
20180108 17:26:27< vn971> zookeeper: ok, to be fair, it's time to take back all my "static state in CPP code" considerations. Indeed they are wrong in a sense that they're not the real issue.
20180108 17:33:09-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 268 seconds]
20180108 17:35:20< Soliton> i think putting each addon in its own namespace won't be that difficult but how to reimplement limited/wanted interaction between addons is the tricky part.
20180108 17:36:09< elias> basically the addon likely would still have a way to do the same damage (it just should not happen by accident as easyily as it does now)
20180108 17:37:05< Soliton> first need to find those interactions which are probably not all that obvious.
20180108 17:38:16< Soliton> perhaps a good idea to open an issue or start a wiki page that explains the current state and can be used to figure out a new design...
20180108 17:43:35< vn971> Soliton: I'm trying to write an issue right now, but let's see whether it'll be good. (I'm not native to English, not to mention my wesnoth internals knowledge is still limited.)
20180108 17:43:47< vn971> *is still very limited
20180108 17:58:01< vn971> done  https://github.com/wesnoth/wesnoth/issues/2359
20180108 17:58:29< vn971> feel free to change any aspects, I know I may have missed things.
20180108 18:06:51< vn971> Ravana_: I'm not sure you'll get PM-s if I'll write. See above the issue with "Death Baron", "Skeleton" and Default Era please.
20180108 18:17:47-!- vladimirslavik [vslavik@wesnoth/translator/VladimirSlavik] has quit [Quit: Leaving]
20180108 18:29:39-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20180108 18:35:42-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20180108 18:38:48-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20180108 18:42:56-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev
20180108 18:51:07< Ravana_> annoying to test anything without ageless, debug mod expects some Lua from it
20180108 18:51:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20180108 18:54:06< Ravana_> cant replicate, death baron advancement is not offered
20180108 18:55:06< vn971> Ravana_: we can move to PM if that's convenient. Which side has no "Death Baron" advancement option? The host (who has Ageless) ?
20180108 19:17:05< vn971> * UPD: Ageless Era is not at fault here. Instead my Creep Wars code probably is, because it "downgrades" leaders, meaning that it transforms into other types that only advance to the original. There is no rule to forbid advancing from other Era to Default Era though, so "downgrading" may result in foreign Era.
20180108 19:17:05< vn971> It could also mean that `wesnoth.unit_types[].advances_from`, which was added a couple of months ago, is OOS-unsafe (if I get it right).
20180108 19:27:25-!- atarocch [~atarocch@93.56.164.28] has quit [Ping timeout: 256 seconds]
20180108 19:47:05-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20180108 20:26:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20180108 21:34:21-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20180108 22:13:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20180108 22:13:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20180108 22:14:58< elias> Soliton: data/tools/wesnoth_addon_manager -p 1.13.x -r some_addon_name_does_not_need_to_exist
20180108 22:15:08< elias> Soliton: that works for me, just says "addon does not exist"
20180108 22:16:00< vultraz> elias: did you get that message about the wmlunits update script?
20180108 22:16:22< elias> which one?
20180108 22:16:47< elias> I got a message, but it was a PM
20180108 22:16:48< Soliton> elias: ah, unfortunate. do you have a test addon to upload? hopefully that triggers it.
20180108 22:16:55< vultraz> that
20180108 22:17:11< vultraz> did you deem it credible given our setup?
20180108 22:17:28< elias> Soliton: yes, I'll create a test addon I guess, just wanted to make sure it's not fixed already
20180108 22:17:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20180108 22:18:02-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20180108 22:18:04< elias> vultraz: yeah, I think he suggests something reasonable, even though I don't think there is a way to abuse it currently :P
20180108 22:18:52< Soliton> yeah, it's credible but not really a big deal.
20180108 22:19:21< Soliton> elias: thanks! tell me if you need more help to reproduce. would really like to be able to use the addon manager again.
20180108 22:19:33-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:1c0a:4ff0:4660:76bb] has joined #wesnoth-dev
20180108 22:36:21-!- irker682 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20180108 22:36:21< irker682> wesnoth: Gunter Labes wesnoth:master a535a3140cbc / data/tools/unit_tree/update-wmlunits: Use a more generic default value https://github.com/wesnoth/wesnoth/commit/a535a3140cbc0d76f8ae38c2465ede6924b6d4e1
20180108 22:36:45< vultraz> security holes are never "not really a big deal"
20180108 22:36:54< vultraz> Please apply the appropriate fix
20180108 22:37:00< Soliton> see above
20180108 22:37:34< Soliton> very difficult to view that as a security hole.
20180108 22:42:43< irker682> wesnoth: Gunter Labes wesnoth:1.12 f423bd083f7d / data/tools/unit_tree/update-wmlunits: Use a more generic default value https://github.com/wesnoth/wesnoth/commit/f423bd083f7d3ac3898505bed7e0bb7644bfe8e5
20180108 22:45:24< irker682> wesnoth: Gunter Labes wesnoth:1.12 51f250ca8e49 / data/tools/unit_tree/update-wmlunits: Use a more generic default value https://github.com/wesnoth/wesnoth/commit/51f250ca8e49f675c3e428e49b7c41f1143d668c
20180108 22:55:17< Soliton> elias: do you know if the EXTRA_*_OPTIONS variables still needed in update-wmlunits?
20180108 22:56:26< Soliton> elias: no need to investigate just if you know from the top of your head.
20180108 23:25:31-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180108 23:25:42-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180108 23:29:36-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20180108 23:40:13-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:1c0a:4ff0:4660:76bb] has quit [Quit: Leaving]
20180108 23:44:17-!- TadCarlucci [~lundberg@74.193.219.119] has quit [Remote host closed the connection]
20180108 23:44:35-!- TadCarlucci [~lundberg@74.193.219.119] has joined #wesnoth-dev
20180108 23:47:59-!- sigurdfd [sigurdfd@dynamic-acs-72-23-110-196.zoominternet.net] has joined #wesnoth-dev
--- Log closed Tue Jan 09 00:00:35 2018