--- Log opened Sat Feb 23 00:00:30 2019 20190223 00:08:31<+wesdiscordbot> @hrubymar10 Have you seen @jyrkive 's latest comment? Can you catch just addon_client::user_disconnect and related exceptions? 20190223 00:11:39<+wesdiscordbot> yes, I have seen it. I can't do that because I don't know how tbh. I don't know C++ so much. I probably can move this try catch into addon part of src, but idk, if it is better fix 20190223 00:11:57<+wesdiscordbot> @josteph ^ 20190223 00:13:56<+wesdiscordbot> @hrubymar10 I'm assuming the try/catch is in the right place or jyrkive would have commented about that. What he said was that you should change std::exception to addon_client::user_disconnect. 20190223 00:14:34<+wesdiscordbot> You may want to catch some more exception types, such as https://github.com/wesnoth/wesnoth/blob/005e7f570698e1561242cea3b45b5fb0a594f82a/src/addon/client.hpp#L40-L43 20190223 00:15:42<+wesdiscordbot> Oh, I get it now 😅 the link you sent explains it. thx 20190223 00:24:13-!- irker477 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190223 00:27:12-!- irker686 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190223 00:27:12< irker686> wesnoth: Martin Hrubý (hrubymar10) wesnoth:fix_3859 9070a3286112 / src/gui/dialogs/multiplayer/lobby.cpp: Handle only addons exceptions https://github.com/wesnoth/wesnoth/commit/9070a32861126e9d7745c5f8409de884bac2e437 20190223 00:27:40<+wesdiscordbot> @josteph is that correct in your opinion? ^ 20190223 00:37:54< irker686> wesnoth/wesnoth:master Allefant cf0b5f2bfa fix format string AppVeyor: 1/4 builds failed 20190223 00:37:55< irker686> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/22578430 20190223 00:54:21-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190223 01:09:48-!- celmin|away is now known as celticminstrel 20190223 03:09:20< irker686> wesnoth/wesnoth:master Nils Kneuper 5b54ed8443 updated Lithuanian translation AppVeyor: All builds passed 20190223 04:53:01<+wesdiscordbot> Hm I might have said 23 when is meant 24.... 20190223 05:15:43<+wesdiscordbot> yeah, I scheduled the release wrong 20190223 05:15:50<+wesdiscordbot> I meant to do it tomorrow morning 20190223 05:15:52<+wesdiscordbot> not today 20190223 05:16:24< celticminstrel> Well I doubt anyone will really care if you delay one day from the announced time anyway. 20190223 05:17:03< celticminstrel> BTW, is the changelog all up-to-date and stuff? 20190223 05:17:35<+wesdiscordbot> I'm not sure 20190223 05:18:05<+wesdiscordbot> btw i asked you if the logger was warn or warning 20190223 05:18:17< celticminstrel> I don't remember you asking me this. 20190223 05:18:30< celticminstrel> I think it's warn? But you could easily just try both and see which works. 20190223 05:18:56<+wesdiscordbot> the wiki says warning 20190223 05:19:02<+wesdiscordbot> most places use warning 20190223 05:19:09<+wesdiscordbot> except the [kill] impl uses warn 20190223 05:19:12<+wesdiscordbot> and err 20190223 05:19:16<+wesdiscordbot> instead of the usual error 20190223 05:19:26< celticminstrel> I wouldn't be surprised if both work TBH. 20190223 05:34:52< irker686> wesnoth/wesnoth:1.14 Nils Kneuper 005e7f5706 updated Lithuanian translation AppVeyor: All builds passed 20190223 07:07:34<+wesdiscordbot> @Vultraz Does that mean the string freeze for 1.14.7 starts one day later as well? 20190223 07:07:57<+wesdiscordbot> Yes 20190223 07:40:36-!- commavir [~vir@23.226.237.192] has quit [Remote host closed the connection] 20190223 08:23:26< irker686> wesnoth/wesnoth:1.14 Martin Hrubý (hrubymar10) 64164da994 Handle only addons exceptions AppVeyor: All builds passed 20190223 08:55:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190223 09:04:57<+wesdiscordbot> @hrubymar10 I think you shouldn't catch invalid_server_address or not_connected_to_server at all here. They aren't supposed to happen in the lobby. 20190223 09:05:42<+wesdiscordbot> from lobby you are able to connect just to official addon server? 20190223 09:05:52<+wesdiscordbot> In addition, please don't log an error if you catch a exit or disconnect exception. They occur if the player cancels. Thus, they are part of normal operation, not an error. 20190223 09:06:10<+wesdiscordbot> ok 20190223 09:08:27-!- Ravana [~Ravana@wesnoth/mp-mod/ravana] has quit [] 20190223 09:12:22<+wesdiscordbot> Looking at it, it's indeed possible to connect to a different server in the lobby. The selected server is remembered in preferences. 20190223 09:12:41<+wesdiscordbot> Still, please don't just swallow the exception and log an error. Show a message box instead. 20190223 09:13:07<+wesdiscordbot> Otherwise the player will be completely lost, because nothing happens when they try to download an add-on. 20190223 09:13:28<+wesdiscordbot> (Can't be done before the string freeze is lifted because a message box needs a new player-visible string.) 20190223 09:52:22<+wesdiscordbot> ok, so can I now just let it log to console and create issue for 1.14.7 to create message box? (which I don't know how to create (yet)) @jyrkive 20190223 09:53:23<+wesdiscordbot> For now, I'd prefer if you didn't catch the invalid_server_address and not_connected_to_server exceptions at all. 20190223 09:53:56<+wesdiscordbot> Catching an exception can create a false sense of security "it's already handled". 20190223 09:56:25<+wesdiscordbot> and about logging to console for now? 20190223 09:57:02<+wesdiscordbot> If you don't catch the exception, you can't log it either. 20190223 09:57:16<+wesdiscordbot> And for the other two exceptions, they occur in normal operation. 20190223 09:57:45<+wesdiscordbot> You can log them if you want, but then they should be at info level, not error. 20190223 09:59:01<+wesdiscordbot> Can I have unused ex object like that? try { return ad_hoc_addon_fetch_session(needs_download); } catch (const addons_client::user_exit& ex) { } catch (const addons_client::user_disconnect& ex) { } 20190223 09:59:23<+wesdiscordbot> No, some compilers will complain. 20190223 09:59:52<+wesdiscordbot> Xcode will complain with warning in DEBUG target 20190223 10:00:42<+wesdiscordbot> cpp try { return ad_hoc_addon_fetch_session(needs_download); } catch (const addons_client::user_exit&) { } catch (const addons_client::user_disconnect&) { } 20190223 10:01:05<+wesdiscordbot> You aren't required to create named variables for the exceptions. 20190223 10:01:40<+wesdiscordbot> that's different from C#, Java, ... 😄 20190223 10:03:56<+wesdiscordbot> C# also allows catching exceptions without creating a variable. A quick check shows that I do it myself in some places in another project of mine. 20190223 10:04:11< irker686> wesnoth: Martin Hrubý (hrubymar10) wesnoth:fix_3859 0df243e46c32 / src/gui/dialogs/multiplayer/lobby.cpp: Remove invalid_server_address and not_connected_to_server exceptions for now and https://github.com/wesnoth/wesnoth/commit/0df243e46c320cacc1dfe6eda3afc14704969250 20190223 10:06:10<+wesdiscordbot> C# example: https://sourceforge.net/p/keppi/code/HEAD/tree/tags/3.72/MediaFoundationAudioDecoder.cs#l349 20190223 10:07:23<+wesdiscordbot> Indeed 20190223 10:07:24<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/548808076824674316/unknown.png 20190223 11:34:08-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Quit: Caught sigterm, terminating...] 20190223 11:35:40-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev 20190223 12:16:07<+wesdiscordbot> Why do stable cycles have separate add-on servers from their respective development cycle? 20190223 12:38:26-!- Ravana [~Ravana@wesnoth/mp-mod/ravana] has joined #wesnoth-dev 20190223 12:57:36< Ravana> because until some point, API can change 20190223 13:04:53-!- irker686 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190223 13:17:53-!- joostv [joostmatri@gateway/shell/matrix.org/x-dwqwospslzppcjvr] has joined #wesnoth-dev 20190223 13:29:43-!- joostv [joostmatri@gateway/shell/matrix.org/x-dwqwospslzppcjvr] has left #wesnoth-dev ["User left"] 20190223 13:31:33-!- irker502 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190223 13:31:34< irker502> wesnoth: Martin Hrubý wesnoth:1.14 856183067f09 / src/gui/dialogs/multiplayer/lobby.cpp: Fix game crash when user click on Cancel while connecting to add-ons server from https://github.com/wesnoth/wesnoth/commit/856183067f0999e228338c4ebf402165b198fbf6 20190223 13:39:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190223 14:01:48< elias> "MSBUILD : error MSB4017: The build stopped unexpectedly because of an unexpected logger failure." hm... I don't see how my PR could have caused that, I think irker686 is lying 20190223 14:40:09-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20190223 14:42:55< irker502> wesnoth: Celtic Minstrel wesnoth:localized_sounds 14cfa213167d / src/ (8 files in 2 dirs): Extend the image localization system to sounds and music https://github.com/wesnoth/wesnoth/commit/14cfa213167de062b60528ef86f35db6787e4fe3 20190223 14:46:03< celticminstrel> @hrubymar10 - That post about new saves location makes it sound as if the entire Wesnoth folder is moved, including add-ons, editor maps, etc. Is that true? If so, it's kinda a stretch that it won't affect developers, isn't it? 20190223 15:09:42-!- travis-ci [~travis-ci@ec2-54-88-79-0.compute-1.amazonaws.com] has joined #wesnoth-dev 20190223 15:09:42< travis-ci> wesnoth/wesnoth#20934 (localized_sounds - 14cfa21 : Celtic Minstrel): The build failed. 20190223 15:09:42< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/497485145 20190223 15:09:42-!- travis-ci [~travis-ci@ec2-54-88-79-0.compute-1.amazonaws.com] has left #wesnoth-dev [] 20190223 15:20:48<+wesdiscordbot> celticminstrel: yes, whole wesnoth user dir (addons, caches, saves, maps) is moved. It shouldn’t affect devs much. Dev version of wesnoth creates symlink from old location to the new one. Also there is gist about this change which answers questions related to this change. See changelog for link 20190223 16:04:22< irker502> wesnoth/wesnoth:1.14 Martin Hrubý (hrubymar10) 44b6e373e9 Remove invalid_server_address and not_co AppVeyor: All builds passed 20190223 16:51:35<+wesdiscordbot> was first strike changed to true strike or is that something else? 20190223 16:53:54<+wesdiscordbot> isn't one always attacking first and the other never missing 20190223 16:55:23<+wesdiscordbot> Might be. 20190223 16:57:55<+wesdiscordbot> It doesn't seem to be in the current release though. 20190223 16:58:11<+wesdiscordbot> :thonk: 20190223 16:59:58<+wesdiscordbot> maybe it's a special that was added to one of the reworked campaings? 20190223 17:47:11-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20190223 17:51:53< irker502> wesnoth/wesnoth:localized_sounds Celtic Minstrel 14cfa21316 Extend the image localization system to AppVeyor: vs2017/Release Failed 20190223 17:51:54< irker502> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/22595616 20190223 18:02:47<+wesdiscordbot> Regarding 1.15.0 and Wings of Victory: It will done enough to go in, in what now would be 3 weeks. At the moment it is 'almost done enough'. 20190223 18:03:28<+wesdiscordbot> Also, I'm fairly confident 1.15.0 will be at least mostly compatible with 1.14.x content. I have not seen anywhere near the level of changes in the wml/lua api that there was in the previous cycle. 20190223 18:04:43<+wesdiscordbot> what would be the difference between True Strike and just setting an attack's chance to hit to 100%? 20190223 18:04:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190223 18:07:28<+wesdiscordbot> @sigurdfd Are you comparing 1.15.0 vs 1.14.0 with 1.13.0 vs. 1.12.0 or 1.14.0 vs. 1.12.0? 20190223 18:07:53< irker502> wesnoth/wesnoth:master Celtic Minstrel 89ef64c391 Extend the image localization system to AppVeyor: vs2017/Release Failed 20190223 18:07:54< irker502> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/22595683 20190223 18:08:27<+wesdiscordbot> 1.12.0 vs 1.14.0 20190223 18:08:30<+wesdiscordbot> Important question right here, because a lot of the WML changes in 1.14 didn't happen in 1.13.0 and most of the unexpected ones resulted from people messing about during beta 20190223 18:08:41<+wesdiscordbot> Yep that's what I thought 20190223 18:08:57<+wesdiscordbot> There's no news here 20190223 18:09:41<+wesdiscordbot> (As a side note, 1.12 also had a rather serious case of people doing breaking API changes during beta) 20190223 18:09:53<+wesdiscordbot> Anything that changes the API should be avoided like the plague in beta stage. 20190223 18:10:09<+wesdiscordbot> there were plently prior to beta in 1.13.x as well 20190223 18:11:16<+wesdiscordbot> What I've learned as a content creator is that if you don't port your content right at the beginning of the development cycle and follow every single release from that point onwards you're basically screwed at the end when beta begins 20190223 18:12:01<+wesdiscordbot> Because things snowball later on in response to feedback or once devs snap out of their pre-point-zero release ennui 20190223 18:13:07<+wesdiscordbot> Maybe we should actively tell people to start porting at point zero 20190223 18:13:26<+wesdiscordbot> Or rather not "porting" but future-proofing things with #ifver and other stuff 20190223 18:13:54<+wesdiscordbot> The problem of course is that most people shy away from using dev releases because of the bugs 20190223 18:14:53<+wesdiscordbot> The solution to that would be to have a policy that regressions aren't allowed in the master branch either. 20190223 18:15:08<+wesdiscordbot> In other words, try to always keep the game in a state where it can be released. 20190223 18:15:33<+wesdiscordbot> How the game I develop at work is being done, for example. We prioritize stability over everything else. 20190223 18:16:43<+wesdiscordbot> I did do the porting thing starting around 1.13.4-5? and following the releases. That's why I'm confident about the state of 1.15.0, even though I haven't ported my add-ons yet. 20190223 18:16:47<+wesdiscordbot> I was talking about more surreptitious bugs that you can't avoid 20190223 18:16:57<+wesdiscordbot> Not AR-scale breakage 20190223 18:17:31<+wesdiscordbot> Are the "more surreptitious bugs" severe enough to keep players from trying dev releases? 20190223 18:18:31<+wesdiscordbot> Players are not devs 20190223 18:18:52<+wesdiscordbot> I remember playing version 1.1.6 and running into a bug that caused most campaigns to be unplayable 20190223 18:19:08<+wesdiscordbot> I just decided to leave it alone and wait for the next release 20190223 18:19:17<+wesdiscordbot> (also team colouring was broken in that release and didn't work at all) 20190223 18:19:42<+wesdiscordbot> 1.5.4 (?) was released with a catastrophic bug that rendered all AIs comatose 20190223 18:19:50<+wesdiscordbot> Most people wouldn't play that 20190223 18:20:13<+wesdiscordbot> A 1.7.x or 1.9.x release had a bug where ToD bonuses and penalties didn't work 20190223 18:20:44<+wesdiscordbot> I think there was also a release where teleport didn't work or had unexpected results 20190223 18:21:52<+wesdiscordbot> Hmm. The policy has been working reasonably well in our work project. We recently hired a game designer (who had worked for a much larger company previously) and he actually praised our game (which is still in alpha stage) for its stability. 20190223 18:22:08<+wesdiscordbot> Although it might be easier for us because our project is much smaller than Wesnoth. 20190223 18:23:11<+wesdiscordbot> As a side note, one of Wesnoth's design sins is most evident if you try to load a save from 1.12 into 1.14 where there are units with the teleport ability 20190223 18:23:40<+wesdiscordbot> They gain the ability to teleport to any villages regardless of ownership 20190223 18:24:47<+wesdiscordbot> Most of the ability's implementation is in WML and something changed between 1.12 and 1.14 causing that to happen, and since the WML is carried around by the instanced units as well... 20190223 18:25:41<+wesdiscordbot> Yeah. It wasn't a very good idea to make static WML about unit definitions a part of save files. 20190223 18:45:39<+wesdiscordbot> Oh,I remembera campaign where one of my units iwth teleport turnded to the enemy side (due to story reasons). And could teleport using my viillages too 😄 20190223 18:47:01<+wesdiscordbot> It wasn't bad though, since otherwise it would be a bit pointless with me having all the villages. I thought there was a genius of scenario designer using a custom teleport. 20190223 19:35:16< irker502> wesnoth/wesnoth:1.14 Martin Hrubý 856183067f Fix game crash when user click on Cancel AppVeyor: All builds passed 20190223 19:55:16< celticminstrel> @hrubymar10 - I already saw the gist before my reaction. By affecting devs, I meant addon devs who will now find that their addon has been mysteriously moved to a different location. 20190223 19:56:11< celticminstrel> I do think save files should only be storing something like a diff of the unit with its base type or something. 20190223 19:56:51< celticminstrel> If we didn't allow directly modifying unit attributes, you could probably even store only the list of modifications along with a handful of other important variable keys such as name and experience. 20190223 19:57:24< celticminstrel> It definitely shouldn't be storing the unit's attacks or abilities. 20190223 19:57:41< celticminstrel> Unless of course they differ from the modified base type (ie, base type with all modifications applied). 20190223 19:57:51<+wesdiscordbot> Well, they won't if they will use dev version. If they will use stable version then yes, they won't find Wesnoth_1.14 dir in old direction. 20190223 19:58:04< celticminstrel> Pretty sure most addon devs use 1.14. 20190223 19:58:30<+wesdiscordbot> I am talking about self-compiled 1.14 version, not master one 20190223 19:58:36<+wesdiscordbot> More specifically, the WML implementation of abilities definitely shouldn't be a part of save files. 20190223 19:58:37<+wesdiscordbot> You got me bad 20190223 19:59:00< celticminstrel> Uh, what? 20190223 19:59:16< celticminstrel> Jyrki, yes, definitely. 20190223 19:59:37< celticminstrel> I guess storing only the names of the abilities would be fine. 20190223 20:02:24<+wesdiscordbot> I think the whole paradigm of making abilities part of the game state is bad 20190223 20:02:45<+wesdiscordbot> As opposed to having them be statically defined unless otherwise specified 20190223 20:03:19<+wesdiscordbot> Yeah. There is static game state (like "which abilities exist") and dynamic game state. Saves should only store dynamic game state, not static. 20190223 20:03:24<+wesdiscordbot> celticminstrel: If that "Uh, what?"reply to my message, the I'll explain once more: I used "dev version" phrase before. You probably think that I meant version of wesnoth from master (a.k.a. 1.15.0). But that's incorrect. Sorry for that. I meant self-compile wesnoth from 1.14 branch. 20190223 20:03:41< celticminstrel> Yeah I wanted to do something about that but still haven't gotten around to it. 20190223 20:04:40< celticminstrel> hrubymar: I have no idea WTH you're talking about a self-compiled 1.14. I'm saying addon devs using 1.14.6 on Mac may get confused when they go to their library folder and find the Wesnoth_1.14 folder no longer exists (unless I'm misunderstanding something here). 20190223 20:09:40<+wesdiscordbot> celticminstrel: If you will compile wesnoth from source, then you will got self-compiled wesnoth IMO. That's what self-compiled mean 20190223 20:09:56< celticminstrel> ... 20190223 20:10:00< celticminstrel> I know what it means, thanks. 20190223 20:10:26< celticminstrel> But most players or addon devs won't be doing that, so I'm not sure why you even brought it up. 20190223 20:10:33<+wesdiscordbot> @loonycyborg can we get the pot update 20190223 20:13:41<+wesdiscordbot> celticminstrel: well idk. What should we do in your opinion? AppSandboxing is requirement and I can't change it. I mentioned this change in changelog. What else? Also sandboxed version can't create symlink for you as it doesn't have access to entire filesystem. 20190223 20:14:26<+wesdiscordbot> celticminstrel: I see your point, I just don't know better way to handle this situation. 20190223 20:14:46< celticminstrel> Well, I think my main issue is that the gist implies that the change won't affect anyone, when in fact addon devs are going to find their work moved to a new location. 20190223 20:15:07< celticminstrel> I assume other apps can still access stuff in the Wesnoth "container"... 20190223 20:16:03<+wesdiscordbot> yes, other apps could access wesnoth's sandbox 20190223 20:16:42< celticminstrel> There's the button to open the folder, so maybe it's not a huge problem, but I'd at least recommend making it clearer in the gist that this doesn't apply only to save files but also to addons, preferences, editor maps, etc. 20190223 20:18:05< celticminstrel> (Well, you probably don't need to mention preferences.) 20190223 20:18:27< celticminstrel> (BTW, if the sandboxed version doesn't have access to the whole filesystem, how can it automatically migrate settings on first run?) 20190223 20:18:55<+wesdiscordbot> so what if I'll add this to the gist: Q: I am addon developer, will this change affect me somehow? A: If you will wesnoth compiled from source, then it won't affect you. If not, then you will probably be interested in creating symlink from old location to the new one. See the I want to downgrade to the previous version of wesnoth. Question bellow 20190223 20:19:10< celticminstrel> "If you compile Wesnoth from source" 20190223 20:19:25< celticminstrel> That aside, sure. 20190223 20:19:33<+wesdiscordbot> oh, I changed this sentence during writing 😄 sorry 😄 20190223 20:19:47< celticminstrel> Makes sense, that happens to me sometimes too. 20190223 20:19:48<+wesdiscordbot> @loonycyborg wait with the pot update, I have sth to push first (as usual) 20190223 20:20:08<+wesdiscordbot> ok tell when done 20190223 20:20:14<+wesdiscordbot> okay 20190223 20:21:03< celticminstrel> So how can it automatically migrate settings if it doesn't have access to the whole filesystem? And will the file dialog still have access to the whole filesystem? 20190223 20:21:32<+wesdiscordbot> > (BTW, if the sandboxed version doesn't have access to the whole filesystem, how can it automatically migrate settings on first run?) Well, that's apple policy. During first launch, macOS can migrate your old app data based on this .plist https://github.com/wesnoth/wesnoth/blob/1.14/projectfiles/Xcode/Resources/container-migration.plist 20190223 20:22:38< celticminstrel> Ah. 20190223 20:22:49<+wesdiscordbot> > And will the file dialog still have access to the whole filesystem? Like the one where you can select custom wesnothd executable? Probably yes. I haven't tested tbh 20190223 20:23:14< celticminstrel> Maybe you should test it asap since the release is going forward pretty soon...? 20190223 20:23:34< celticminstrel> Yeah, the one where you can select custom wesnothd, or the load/save map one in the editor... those dialogs. 20190223 20:24:03< celticminstrel> Load/save map is probably easier to access than select wesnothd... when does that even pop up anyway? I've never seen it. 20190223 20:24:08<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/548963285731639322/unknown.png 20190223 20:24:26<+wesdiscordbot> I of course have thing in my home dir 20190223 20:24:34< celticminstrel> So that means it doesn't work, right? 20190223 20:25:20<+wesdiscordbot> from apple's side of view everything works just fine: sandboxed app can't go outside of it's sandbox 20190223 20:25:30<+wesdiscordbot> It's probably because we're using our own file dialog instead of the system file dialog. 20190223 20:25:39<+wesdiscordbot> from our side of view no, filelisting doesn't work as expected 20190223 20:25:46<+wesdiscordbot> macOS has no idea that Wesnoth is even showing a file dialog there. 20190223 20:25:46< celticminstrel> But it should be allowed out when the user explicitly requests it. 20190223 20:25:56< celticminstrel> And navigating in a file dialog definitely counts as that. 20190223 20:26:15< celticminstrel> I guess it's not a blocker, since 90% of files that people want to load will be within the userdata directory. 20190223 20:26:25< celticminstrel> Either in the addons dir or the editor dir. 20190223 20:26:42< celticminstrel> But IMO it should be fixed if at all possible. 20190223 20:27:10<+wesdiscordbot> in iOS version is filelisting completely disabled 20190223 20:27:43< celticminstrel> (I assume you do see files when you click on userdata, at least.) 20190223 20:28:03< celticminstrel> (...what if you click on game data?) 20190223 20:28:29<+wesdiscordbot> gamedata works as expected 20190223 20:28:37<+wesdiscordbot> userdata too 20190223 20:28:46<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/548964450376613902/unknown.png 20190223 20:29:43< celticminstrel> Is there some compile-time flag for whether the sandbox is enabled? Maybe for now we could just hide the other three bookmarks if it's enabled. 20190223 20:29:53< celticminstrel> ie Home, Volumes, Root 20190223 20:30:03<+wesdiscordbot> Or even a runtime check. 20190223 20:30:07< celticminstrel> Sure. 20190223 20:30:38< celticminstrel> I still think there needs to be a way to break out of the sandbox for the file dialog, but I guess it's not a priority. 20190223 20:30:50< celticminstrel> We could open an issue for it. 20190223 20:32:37<+wesdiscordbot> I don't think so. Filebrowsing in sandboxed app on macOS looks same as on iOS (where is every app sandboxed) 20190223 20:33:55<+wesdiscordbot> macOS must know that wesnoth shows file dialog. Or it doesn't know/care. macOS probably blocks some boost's functions for filesystem browsing 20190223 20:34:37<+wesdiscordbot> Right now we have a custom file dialog. The only thing macOS knows is that we're calling functions to enumerate directories. 20190223 20:34:53<+wesdiscordbot> Any program can call those functions without showing any UI at all. 20190223 20:38:13<+wesdiscordbot> celticminstrel: I have fixed the gist. What do you think now? : https://gist.github.com/hrubymar10/eb5afd896f933a46fac344ced940e020/revisions 20190223 20:39:41<+wesdiscordbot> Some possible improvements. 20190223 20:39:44<+wesdiscordbot> bellow -> below 20190223 20:39:56<+wesdiscordbot> You wrote "wesnoth" in lowercase in a couple of places. 20190223 20:40:13<+wesdiscordbot> You could make "open terminal" a link as well. 20190223 20:41:24<+wesdiscordbot> Oh, and Enter should also be written in uppercase. 20190223 20:41:30< celticminstrel> I mean, in the worst-case scenario you could just actually use the native file dialog. 20190223 20:41:47< celticminstrel> Assuming that's allowed for a sandboxed app, obviously. 20190223 20:42:16< celticminstrel> Grammar fix: "has a new location" (missing article) 20190223 20:42:37< celticminstrel> IMO "on first run" sounds better than "during first run" but YMMV. 20190223 20:42:49< celticminstrel> "creating a symlink" 20190223 20:42:56< celticminstrel> "the old location" 20190223 20:43:03< celticminstrel> "below" has only one L 20190223 20:43:15< celticminstrel> That happens at least twice. 20190223 20:43:59< celticminstrel> Missing "the" for old location also happens twice. 20190223 20:44:55< celticminstrel> So the symlink command is absolutely safe? Like, MacOS won't suddenly decide to move the container to a different location or anything? 20190223 20:45:06< celticminstrel> I wonder if there's a command-line program that creates an alias... 20190223 20:45:11< celticminstrel> Probably not, right...? 20190223 20:45:47<+wesdiscordbot> is that correct? .... automatically link the old saves location ... 20190223 20:46:16< celticminstrel> Should be. 20190223 20:46:26< celticminstrel> Assuming it's followed with something like "to the new location". 20190223 20:46:58<+wesdiscordbot> yes, it is 20190223 20:47:44<+wesdiscordbot> thank you for grammar corrections. I am not native speaker and I am not best in English. I am not good at languages 😦 20190223 20:48:04<+wesdiscordbot> Your English is very good for a non-native speaker. 20190223 20:48:45<+wesdiscordbot> Well, thank you. I appreciate that you say it. 20190223 20:49:40<+wesdiscordbot> > So the symlink command is absolutely safe? I hope so. But the location is same since OS X 10.9 which IIRC introduced app sandboxing on macOS 20190223 20:50:23<+wesdiscordbot> Also we won't and even can't change bundle id (org.wesnoth.Wesnoth) 20190223 20:50:23< celticminstrel> I see. 20190223 20:50:35< celticminstrel> (What's the latest version now anyway?) 20190223 20:50:48< celticminstrel> ...why can't you change the bundle ID if you wanted to? Not that you'd want to... 20190223 20:51:15<+wesdiscordbot> latest version of macOS? macOS 10.14 Mojave 20190223 20:52:08<+wesdiscordbot> The app is registered under bundle ID. You can't change bundle ID of existing app. You have to release new app instead. 20190223 20:52:38<+wesdiscordbot> is registered at Mac AppStore 20190223 20:53:05<+wesdiscordbot> It's a pain because the bundle ID needs to be set pretty much at the start of development. 20190223 20:53:33<+wesdiscordbot> For our game project at work, we decided to use the game's codename on Android and placeholder name on iOS. 20190223 20:54:01<+wesdiscordbot> Those are both final bundle IDs, and we won't change them, even though the final name may be something completely different. 20190223 20:54:16<+wesdiscordbot> > I wonder if there's a command-line program that creates an alias... I don't understand this question. Are you talking about old apple's symlink implementation? 20190223 20:54:32< celticminstrel> Why would it need to be set at the start of development? Can't you just set it when you first release? 20190223 20:54:50<+wesdiscordbot> on iOS not 20190223 20:54:54< celticminstrel> @hrubymar10 - No I'm talking about aliases in the Finder, which are different from symlinks. 20190223 20:54:57< celticminstrel> And why not? 20190223 20:55:10< celticminstrel> It's not on the app store at all until you release it, right? 20190223 20:55:21<+wesdiscordbot> you can't even test it on team devices without proper signing which means registering app 20190223 20:55:52<+wesdiscordbot> External services are also tied to the bundle ID and need to be set up again if the bundle ID is changed. 20190223 20:59:08<+wesdiscordbot> https://stackoverflow.com/questions/18452596/whats-the-difference-between-ln-s-and-alias 20190223 20:59:55<+wesdiscordbot> oh but that's something different 20190223 21:03:14<+wesdiscordbot> celticminstrel: ok, so basically macOS' alias works pretty same as ln -s but alias is dynamic. If you will move the target to the new location, alias will still point to it. ln -s won't. 20190223 21:03:24<+wesdiscordbot> Reference: https://en.wikipedia.org/wiki/Alias_(Mac_OS) 20190223 21:03:56<+wesdiscordbot> I think that's a different thing than modern macOS aliases. 20190223 21:04:12<+wesdiscordbot> macOS isn't a successor of Mac OS. It's essentially an unrelated OS. 20190223 21:04:46< celticminstrel> I don't know if it's the same, but it works more or less the same way, so I think it's reasonable to call it the same. 20190223 21:05:08<+wesdiscordbot> Mac OS -> Mac OS X -> OS X -> macOS 20190223 21:05:18<+wesdiscordbot> Aliases are only for interactive shells, symlinks can be used in scripts too 20190223 21:05:19<+wesdiscordbot> Mac OS X was a full rewrite. 20190223 21:05:27< celticminstrel> Yes, but they kept aliases around. 20190223 21:05:44< celticminstrel> @sevu - No, that's completely different from a Finder alias. 20190223 21:06:22< celticminstrel> A symlink references a path. If you move the target, it no longer works. If you recreate the target, it resumes working. (Correct me if I'm wrong?) 20190223 21:06:38<+wesdiscordbot> that's correct 20190223 21:06:44< celticminstrel> An alias references a file or directory. No matter where you move it on the same volume, it will always refer to the same file or directory. 20190223 21:06:59< celticminstrel> They appear the same in the Finder, though. 20190223 21:07:23<+wesdiscordbot> also correct 20190223 21:07:24<+wesdiscordbot> There are also hard links. With hard links, the same file exists in multiple directories, potentially with different names. 20190223 21:07:42< celticminstrel> Yes, there are hard links too. Not sure how those appear in the Finder... I think it doesn't mark them? 20190223 21:07:56<+wesdiscordbot> yes, but hardlink is somethink different from links in macOS 20190223 21:07:59< celticminstrel> An alias isn't a hard link though. 20190223 21:08:05< celticminstrel> What do you mean? 20190223 21:08:36< celticminstrel> FTR, MacOS supports hard links and can even do it on directories (though I don't think ln allows this). 20190223 21:09:22< celticminstrel> (At least, it did as of my version, 10.7, but I don't see any reason why they would've removed that feature; it was added for Time Machine, most likely.) 20190223 21:10:30<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/548974958668414996/unknown.png 20190223 21:10:44<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/548975013399756800/unknown.png 20190223 21:11:35<+wesdiscordbot> So macOS 10.14 can do hardlinks (timemachine uses hardlinks), but finder doesn't mark them somehow 20190223 21:11:49< celticminstrel> Yeah, that's what I thought. 20190223 21:12:14<+wesdiscordbot> Some nitpicking: with hard links, there isn't a concept of "original file", so it's incorrect to call either of them "original". 20190223 21:12:23< celticminstrel> Time Machine even hard-links directories, according to Ars Technica. 20190223 21:12:25<+wesdiscordbot> You can delete either of them and the other will continue to work. 20190223 21:12:29<+wesdiscordbot> and of course if I'll edit for example link.go, the change is applied also in original.go 20190223 21:12:48-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [] 20190223 21:14:19< celticminstrel> Aliases also aren't resolved by command-line tools. 20190223 21:14:37<+wesdiscordbot> ln command can't do hardlinks on dirs, but in general macOS can do it: https://stackoverflow.com/questions/1432540/creating-directory-hard-links-in-mac-os-x 20190223 21:16:37< celticminstrel> Apparently apfs doesn't support hard-links? o.o 20190223 21:19:11<+wesdiscordbot> apfs does support hardlinks 20190223 21:22:47< celticminstrel> So the comment was inaccurate then, okay. (Or they added support later.) 20190223 21:30:24-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20190223 21:34:52-!- valdar [~atarocch@93.56.172.28] has quit [Ping timeout: 272 seconds] 20190223 21:36:02< irker502> wesnoth/wesnoth:1.14 doofus-01 7888b4842f mermaid siren defense animation AppVeyor: All builds passed 20190223 21:37:26<+wesdiscordbot> celmin, the wml.tostring{foo=_"bar"} thing might be e692294532f5b647ad5739614a11c1eebbf50884? 20190223 21:38:03< celticminstrel> Hm? 20190223 21:38:25<+wesdiscordbot> the thing that works in master but not in 1.14? 20190223 21:38:29<+wesdiscordbot> from the forum thread? 20190223 21:39:11< celticminstrel> I get what you're talking about, but... 20190223 21:39:25< celticminstrel> A commit hash is kinda meaningless. 20190223 21:39:29< celticminstrel> Is that on master or 1.14? 20190223 21:39:45< irker502> wesnoth: Severin Glöckner wesnoth:1.14 0041b0c9e046 / po/ (17 files in 17 dirs): German translation update for 1.14.6 https://github.com/wesnoth/wesnoth/commit/0041b0c9e046d871faf6efd8e20dea644ca0bab6 20190223 21:39:47<+wesdiscordbot> it's on master 20190223 21:39:57<+wesdiscordbot> but git show would have worked in either case.... 20190223 21:40:02< celticminstrel> Is there an equivalent on 1.14? 20190223 21:40:15<+wesdiscordbot> it backports cleanly, but doesn't compile 20190223 21:40:23< celticminstrel> Hmm. 20190223 21:40:37<+wesdiscordbot> write() doesn't exist 20190223 21:40:48< celticminstrel> Probably need to add an include... 20190223 21:41:09< celticminstrel> Maybe serialization/parser.hpp 20190223 21:41:30<+wesdiscordbot> @loonycyborg That's all I have, you can make the pot-update 20190223 21:43:44<+wesdiscordbot> nice one celmin, it compiled 20190223 21:44:33<+wesdiscordbot> and works too 20190223 21:44:39<+wesdiscordbot> shall I commit? 20190223 21:44:47< celticminstrel> Sure. 20190223 21:45:03<+wesdiscordbot> and just in time for the release too, thank you for that 😃 20190223 21:47:46< celticminstrel> FTR I personally have no objection to the PR being merged too for this release, but maybe get a few more opinions. 20190223 21:48:24< irker502> wesnoth: Celtic Minstrel wesnoth:1.14 be3ebd53aa71 / changelog.md src/scripting/lua_kernel_base.cpp: Lua API: Make wml.tostring a lossless conversion https://github.com/wesnoth/wesnoth/commit/be3ebd53aa71d3e4821197f34cbd89a9245d47d6 20190223 21:49:11<+wesdiscordbot> it failed travis 20190223 21:49:26<+wesdiscordbot> and in any case, can it even be backported? 20190223 21:49:29<+wesdiscordbot> or does it count as a new API 20190223 21:49:40< celticminstrel> Well, that's a good question. 20190223 21:49:54< irker502> wesnoth: Severin Glöckner wesnoth:1.14 8ebee2fdc374 / po/wesnoth-lib/de.po: German translation – fix terminology https://github.com/wesnoth/wesnoth/commit/8ebee2fdc37451d92171cde6d448cd59520baf0e 20190223 21:50:23< celticminstrel> Certainly it wouldn't cause any problems with older addons, and someone using an addon made to work with it on 1.14.5 or earlier would just hear the nonlocalized sounds. 20190223 21:50:30<+wesdiscordbot> Is anyone going to review lordlewis's art by the way? Five or six sprites by now https://forums.wesnoth.org/viewtopic.php?p=638841#p638715 20190223 21:50:46<+wesdiscordbot> celmin, it's backward compatible but not forward compatible 20190223 21:51:08<+wesdiscordbot> if we don't backport it then we should start thinking of 1.15.0. 20190223 21:51:11<+wesdiscordbot> Non-forward-compatible changes aren't allowed in the stable branch either. 20190223 21:51:18<+wesdiscordbot> There have been several such cases already 20190223 21:51:36<+wesdiscordbot> celcticminstrel, wouldn't be a regression though, preople hear unlocalized sounds now too 20190223 21:52:24<+wesdiscordbot> so, now that I think of it 20190223 21:52:36<+wesdiscordbot> 1.14.7 is scheduled to next week 20190223 21:52:38< celticminstrel> ...WTH does it complain that the sound namespace is missing... 20190223 21:52:41<+wesdiscordbot> can't we do 1.15.0 instead? 20190223 21:52:59< celticminstrel> ...wait, was my number off for the new release? 20190223 21:53:10< celticminstrel> Or are we making two stable releases in a short amount of time? 20190223 21:53:15<+wesdiscordbot> the latter 20190223 21:53:20< celticminstrel> Weird. 20190223 21:53:21<+wesdiscordbot> 1.14.6 in two hours. 1.14.7 in a week 20190223 21:53:35< celticminstrel> Well, in that case, no need to worry about the localized sounds for 1.14.6. 20190223 21:53:41< celticminstrel> If we decide to backport it can be in 1.14.7. 20190223 21:53:43<+wesdiscordbot> String freeze is in a week, it's because of the DiD changes 20190223 21:55:44<+wesdiscordbot> either way, we should start thinking about a 1.15.0 at some point 20190223 21:55:57<+wesdiscordbot> like I said, this isn't the first one-way-compatible change that had to be left out 20190223 21:56:08<+wesdiscordbot> those changes need to be released at some point 20190223 21:58:48< irker502> wesnoth: loonycyborg wesnoth:1.14 88e4f49e42db / / (460 files in 16 dirs): pot-update and regenerate doc files https://github.com/wesnoth/wesnoth/commit/88e4f49e42dbb0bd5a6819b82bb6ea25c8e88039 20190223 21:59:40< celticminstrel> FTR, if you don't want to backport the PR, you can still use the string it relies on to get the current language. 20190223 22:00:10< celticminstrel> And then construct a path equivalent to what the localization system would use (ie, l10n/en/filename instead of just en/filename). 20190223 22:01:45<+wesdiscordbot> yeah, I'll do that 20190223 22:12:50<+wesdiscordbot> done, updated the thread, last post 20190223 22:13:35< irker502> wesnoth: Severin Glöckner wesnoth:master dc69cd5f4119 / data/campaigns/Under_the_Burning_Suns/scenarios/03_Stirring_in_the_Night.cfg: UtBS: change textdomain https://github.com/wesnoth/wesnoth/commit/dc69cd5f41197a644a23e52f745ce95405f0267a 20190223 22:19:02< irker502> wesnoth: Severin Glöckner wesnoth:master 034618a33d45 / data/core/units/monsters/Fire_Dragon.cfg: Help: remove space between sprite and text for Fire Dragon https://github.com/wesnoth/wesnoth/commit/034618a33d45a44addb5d253b8438ca0fb7bbbf2 20190223 22:30:36-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20190223 22:31:00<+wesdiscordbot> @loonycyborg thanks 20190223 22:31:13-!- TheJJ_ [~rofl@ipbcc0608f.dynamic.kabel-deutschland.de] has quit [Quit: løl] 20190223 22:51:24< irker502> wesnoth: Charles Dang wesnoth:1.14 fb522fd923c7 / Doxyfile changelog.md projectfiles/Xcode/Info.plist src/wesconfig.h: Pre-release version bump https://github.com/wesnoth/wesnoth/commit/fb522fd923c78a777b5cb4b264672c4ded5c59a9 20190223 22:51:53< irker502> wesnoth/wesnoth:localized_sounds Celtic Minstrel 14cfa21316 Extend the image localization system to AppVeyor: 2/4 builds failed 20190223 22:51:54< irker502> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/22595616 20190223 22:51:55< irker502> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/22595617 20190223 23:07:54< irker502> wesnoth/wesnoth:master Celtic Minstrel 89ef64c391 Extend the image localization system to AppVeyor: 2/4 builds failed 20190223 23:07:55< irker502> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/22595683 20190223 23:07:56< irker502> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/22595684 20190223 23:11:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190223 23:12:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190223 23:40:25-!- TheJJ [~rofl@ipbcc0608f.dynamic.kabel-deutschland.de] has joined #wesnoth-dev 20190223 23:42:44-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds] --- Log closed Sun Feb 24 00:00:31 2019